In program execution, you’re only as good as your last assignment, and success rarely makes headlines. That was my life in the corporate world: steady, structured, predictable. Then I found blockchain, where the rules I knew simply didn’t apply. Decision-making was distributed, transparency near-total, and the pace unforgiving. Delivery stopped being orderly and became controlled chaos — and I loved it.
My path into delivery was unusual. I began in experimental physics, where progress depends on precision, observation, and iteration. Experiments rarely behave as theory predicts, so you adapt fast and record everything. I left research looking to build beyond the theory, to see ideas take shape in the real world. Delivery gave me that same discipline and curiosity, but with tangible results.
The Glacier Drop pushed that to the limit: the first airdrop to span eight chains, led by the Midnight TGE and supported by teams from Shielded, Input Output, Midnight Foundation, and other partners, delivered under public scrutiny and constant time pressure. This piece reflects on how our teams delivered it — not the code, but the execution that made it work. Because in delivery, understanding what you build starts with knowing who you’re building for.
1. Always know who you’re building for
Every delivery professional will tell you that to deliver on time and on budget, you must control scope. That rule rarely holds in blockchain. The space evolves fast, with technologies moving from research to production in weeks. Ambition drives constant change: new ideas, new “firsts,” new expectations. Scope rarely stays still long enough to be controlled, and when funding is strong, the usual constraints that enforce trade-offs disappear.
That’s why it becomes essential to know exactly who you’re building for. For the Glacier Drop, we were supporting the Midnight TGE in delivering for the active participants of eight different blockchain communities: Cardano, Bitcoin, Ethereum, Solana, XRP, BNB Chain, Avalanche, and Brave Network. Their experience, access, and trust mattered most. At the same time, we were also realizing the vision of Charles Hoskinson, whose belief in the ecosystem made the program possible.
The challenge wasn’t choosing one over the other, but holding both truths at once: delivering a user-centric experience that lived up to the scale and intent of his vision. It’s not about hierarchy; it’s about clarity. When priorities compete, teams need a shared definition of completion. Knowing whose needs truly set the direction keeps everyone aligned and focused, even as the environment shifts.
But there is another side to this story. Delivering something at this scale also meant reconciling the needs of those we were building for with the motivations of those who were building it. The team brought a wide range of perspectives: the rigor and ethical discipline of deep technical research, the pragmatism of seasoned engineering leadership, a relentless focus on users, fairness, and coherent design, and the operational drive to meet deadlines without compromising compliance.
Some prioritised scope control, others were drawn to solving the hardest technical problems, and others focused on communicating every nuance so the community always understood what was happening. Aligning these viewpoints was its own challenge, but it is also what made the work resilient. In a multi-disciplinary effort like this, the final product inevitably reflects both sides: the expectations of the people you build for, and the values of the people who build it.
2. Turn complexity into control
Ambition always comes at a cost. When you’re the first to build something novel, dependencies multiply, and hidden costs appear. Some of that complexity came from the technology choices that enabled the program to scale. On the Cardano side, we used Hydra, a Layer 2 protocol designed for high-throughput off-chain execution. Hydra gave us the performance headroom we needed, but it also introduced a second execution environment with its own testing, monitoring, and operational behaviors.
Wallet support added similar challenges. We worked across eight chains, with different signing standards, UX flows, and vendor-specific quirks that often shifted between versions. It was a massive undertaking, and to achieve the broadest possible compatibility, some trade-offs were inevitable. That’s simply the reality of integrating new technologies at pace, along with disciplined configuration control, clear ownership, and careful debugging to keep delivery on track.
The Glacier Drop carried a complexity tax levied in time, coordination, energy, and sleepless nights. Managing that tax required transparency, perseverance, and constant recalibration. No single team could have delivered it alone. Midnight TGE brought together Shielded, Input Output, and contractors, partners, and vendors into one blended, but highly-matrixed team with a shared mission. Each one came from different delivery cultures, but we built a common rhythm — shared stand-ups, single communication channels, and joint rituals where they mattered. When people feel part of one story, not separate silos, they carry each other through uncertainty.
Delivery frameworks helped, but they didn’t deliver the program. Agile, Kanban, OKRs, and PRINCE2 each served a purpose, but none of them were sufficient on their own. We used work-breakdown structures for planning and agile methods where iteration helped most. What mattered were the people with foresight to anticipate risks, judgment to adapt when plans diverged, and persistence to keep moving. Frameworks provide scaffolding; people make it stand.
One delivery pattern proved invaluable: pairing a Technical Program Manager with an Engineering Manager and a strong Product Lead. The TPM provided cadence and stakeholder alignment. The EM brought technical authority and credibility with developers. The Product Lead kept priorities sharp and made the trade-offs that kept delivery on course. Together they built a bridge between ambition and implementation, ensuring decisions in meetings translated cleanly into code.
That partnership became the backbone of Glacier Drop. In a delivery defined by moving parts, multiple vendors, and unforgiving deadlines, it gave the team clarity and control without slowing momentum. It’s a model I would choose again in any high-stakes, multi-party program - rigor and velocity, held in balance.
3. Anchor ambition with integrity
If the Glacier Drop were to fail, it wouldn’t have been because of code. It would’ve been because of everything around it. In blockchain, independent security audits and distributed approval processes are what make innovation trustworthy, and what make delivery harder.
Independent audits are non-negotiable. They protect users, funds, and reputation. But they’re also slow, expensive, and highly sensitive to change. Even a minor update can trigger a full re-audit. Keeping audits aligned with delivery required constant coordination and careful trade-offs.
At times, waiting for an external audit would have put the rest of the program at risk. In those situations, we supported releases of components that had been rigorously reviewed internally, always within the Midnight TGE’s governance and approval framework. QA ran relentlessly and nonstop, sometimes through weekends or holidays, with external audits running in parallel or immediately post-hoc. These decisions were never casual. They were the only pragmatic way to keep interdependent work moving while still honoring our assurance obligations.
Distributed approval added another layer of complexity. Every smart-contract deployment or update required multiple parties to review and sign before anything could go live. This was by design. Glacier Drop paved the way for Midnight, a privacy-enhancing network built so that no single entity could act alone. That structure slows you down, but it creates resilience and integrity in places where trust cannot be assumed.
Audits – internal and external – and extensive testing safeguard the code; distributed approvals protect against single points of failure. Both added delays, rework, and coordination overhead, and both were essential.
Our teams held the line under pressure, balancing assurance with deadlines and proving that security and speed can coexist — though never comfortably. And none of this would have worked without deep technical authority: the people who knew how to make structure real.
4. Let the experts lead
Complex delivery isn’t just about coordination; it’s also about depth. The Glacier Drop demanded every layer of expertise working together: architects, product designers, front-end and back-end developers, SREs (site reliability engineers), QA engineers, product managers, product marketing specialists, and developers who understood smart contracts at every layer, from logic to execution. Each discipline was essential. Each became the safety net for the others.
Take user acceptance testing as an example. With everyone reviewing the same builds, issues surfaced from sources no test plan would have predicted. Some bugs were even informally named after the team member who first spotted them, a ritual that took on a life of its own and proved a simple truth –- on this program, anyone could be the one who saved the day.
Our architects were nothing short of brilliant. They absorbed shifting scope, last-minute additions, and untested technologies, and still kept the program moving forward. They didn’t just design systems; they protected technical integrity. Their judgment gave everyone, from executives to engineers, the confidence that security and reliability were never compromised.
But architecture alone wasn’t enough. Product designers shaped complex workflows into experiences people could actually use. QA bore the final weight, nothing could move without their validation and verification. SREs kept delivery stable under unpredictable loads. Front-end and back-end engineers translated complex logic into interfaces and services that worked seamlessly across chains. Product marketing specialists translated technical achievement into understanding and trust, ensuring the airdrop was not only functional, but by flagging complex external interdependencies and keeping the program visible and clear across all working groups and the community. And when smart contract issues appeared –- the kind only a handful of people in the world can solve –- our domain experts stepped in and solved them, often under intense time pressure.
It takes a village to build something like the Glacier Drop. Ours was made up of people from different organizations, time zones, and disciplines. For the duration of the program, we collaborated closely. What mattered wasn’t hierarchy or affiliation; it was competence, judgment, and the ability to stay calm under pressure. That shared professionalism was the real delivery framework, the one that made everything else possible.
5. Manage the blast radius
Delivery in blockchain is never private. It happens in real time, under pressure, and in public. A single tweet can shift expectations or rewrite timelines overnight. The Glacier Drop made that clear from the start. The community scrutinized every step, and their reactions shaped the program almost as much as our plans did.
Not every issue that surfaced was ours to fix, but perception made it ours regardless. Wallet behavior varied across chains, configurations, and operating systems. Some incompatibilities stemmed from external vendors, but users don’t see those boundaries. To them, it either works, or it doesn’t.
That’s why we treated users as part of delivery, not just recipients. We released incrementally, supported them directly, and treated feedback as another diagnostics tool. Managing the blast radius meant anticipating what could go wrong and having a plan –- sometimes just a sketch on the back of an envelope — ready before it did. It also meant staying calm amid noise, communicating clearly, and separating what was critical from what was merely important.
In blockchain, the launch isn’t the end of delivery; it’s the beginning of live experimentation. The real test of resilience is not how well you deliver when everything is planned, but how you adapt when the plan no longer matters.
Toward Midnight
The Glacier Drop stands on its own as a technical and operational achievement, but it was never meant to be a finish line. It was one tick of the clock toward Midnight, a protocol built to make privacy practical, programmable, and human again.
In a world where data exposure has become routine, privacy is no longer a niche concern. It is the foundation of digital trust. Businesses, institutions, and individuals will need systems that protect what matters without slowing progress. That is what Midnight exists to do — and Glacier Drop was its first proof of discipline and intent.
To everyone who built it: thank you for making privacy real, one drop at a time.
…
→ Glacier Drop continues to live for as long as the Redemption phase remains open.