Ten Minutes to Technical Manager: The ICONZ Gamble
Return to Part 0: Table of ContentsPrevious Article: Episode 3 — The Tanenbaum-Torvalds Debate: Why "Worse" Won
A Concise History of Linux: 1991-1996Episode 4
The Shortest Interview I Ever Had
End of 1996. I had just arrived in New Zealand from Austria, carrying two years of web development experience, a head full of Linux, and very little idea what the local tech scene looked like.
I found ICONZ almost immediately.
The Internet Company of New Zealand was running Linux in production. Not as a curiosity. Not as a lab experiment tucked away in a corner. Linux was the backbone of a commercial ISP serving paying customers across the country. For someone who had spent the previous two years building websites in emacs and compiling kernels on a 486, this felt like walking into a room where everyone already spoke my language.
I applied for a job. What followed was probably the shortest interview I have ever had.
I sat down with the General Manager and the outgoing Technical Manager. Ten minutes later, they offered me the role. Technical Services Manager, responsible for the Security Operations Centre, the Network Operations Centre, product development, technical budgets, and a help desk with fifteen support staff.
Ten minutes. No panel interviews. No psychometric testing. They asked me about Linux, about what I had built, about how I thought about infrastructure. They heard answers that matched the problems they needed solved. The conversation was over before I had finished my coffee.
Why ICONZ Was Running Linux
To understand why that ten-minute interview happened, you need to understand the economics of running an ISP in the mid-1990s.
ICONZ was born in 1992, when Jon Clarke transformed his Status bulletin board system into the Internet Company of New Zealand and relocated from a Parnell garage to Airedale Street, opposite the Telecom central Auckland exchange [1]. By 1994, the operation had grown to 18 dial-up lines and a 48-kilobit MDDS circuit to Auckland University [2]. By 1996, ICONZ had expanded to branches in Auckland, Wellington, Hamilton, and Christchurch. The company was, by several measures, the top ISP in a market that now included roughly 30 providers serving over 160,000 New Zealand internet users [3].
Running an ISP in 1996 meant running infrastructure on a budget that would make a modern cloud architect weep. Every dollar spent on software licences was a dollar not spent on bandwidth, hardware, or staff. The commercial UNIX variants that dominated enterprise computing (Solaris, HP-UX, AIX) were priced for corporations with deep pockets. A small ISP in Auckland could not afford per-seat licensing for an operating system, plus per-seat licensing for a mail server, plus per-seat licensing for a web server, plus support contracts for each.
Linux changed that equation entirely.
The kernel itself was free. Sendmail handled email delivery. BIND resolved domain names. Apache served web pages. Free, open source, and modifiable when something broke or when you needed a feature that did not exist yet. The entire stack that a commercial ISP required, from operating system to application layer, could be assembled from freely available components.
This was not a philosophical statement about software freedom, although the philosophy mattered. This was survival arithmetic. ICONZ could serve an entire country's internet traffic because the software cost was effectively zero, leaving the budget for what actually constrained growth: bandwidth, hardware, and people who knew how to keep it running.
June 1996 had brought Linux kernel 2.0, the first release with symmetric multiprocessing support [4]. The kernel could now use multiple CPUs on 32-bit systems. For ISPs handling increasing connection volumes, this was a meaningful step from hobby operating system toward production platform. The timing was right. The technology was ready. The economics were irresistible.
The Technical Stack of a 1990s ISP
The infrastructure behind a mid-1990s ISP was simultaneously simpler and more precarious than anything we run today.
Dial-up modems were the front door. Customers connected at 28.8 or 33.6 kilobits per second over analogue telephone lines. Each connection consumed a physical modem port and a phone line. Scaling meant buying more modems, more phone lines, more rack space. There was no virtualisation. There was no elastic scaling. Capacity planning meant counting phone lines and hoping you had enough.
Behind the modems sat the servers. A typical ISP of this era ran a handful of Linux or BSD machines, each handling multiple roles. One server might run Sendmail for email, BIND for DNS resolution, and Apache for web hosting simultaneously. Separation of concerns was a luxury for organisations with larger budgets. You made what you had work.
The network connected to the wider internet through leased lines. ICONZ's early circuit to Auckland University ran at 48 kilobits per second [2]. To put that in perspective, a single high-resolution image on a modern website would saturate that link for several seconds. Every byte mattered. Every service had to be lean.
Monitoring was rudimentary by current standards. You watched system logs. You wrote shell scripts to check disk space and connection counts. You set up pagers for the truly critical alerts. When something failed at 3 a.m., someone drove to the data centre. There was no remote management console. There was no cloud dashboard. There was a person with a car key and knowledge of which server needed to be power-cycled.
This was the environment I walked into. And it was exactly the environment where Linux thrived.
Linux and the Startup Temperament
There was a cultural alignment between early ISPs and the Linux community that went deeper than economics.
ISPs in the 1990s attracted a particular kind of person. The work was technical, unpredictable, and constant. You built systems during the day and debugged them at night. You wore every hat because there was nobody else to wear it. You learned by breaking things and then fixing them under pressure.
Linux attracted the same temperament. The operating system in 1996 was powerful but not polished. Installing it required patience. Configuring it required reading documentation, searching mailing lists, and occasionally reading source code to understand why something was not working. The reward was complete control. If the software did not do what you needed, you could change it. You could recompile the kernel with exactly the drivers your hardware required. You could patch a bug yourself rather than waiting six months for a vendor to acknowledge it existed.
At ICONZ, this alignment was practical. When a new hardware device arrived and the kernel did not support it, someone wrote a driver or found a patch. When a service needed a feature that the packaged version lacked, someone compiled a modified version. The pace of the internet in 1996 did not wait for vendor release cycles. It waited for people who could solve problems with the tools at hand.
I had been one of those people in Europe. Building websites for clients in Innsbruck, writing HTML in emacs, iterating faster than any formal process would allow. My brother-in-law's connections through the Innsbruck Chamber of Commerce brought me clients who needed web presences built yesterday. The process was always the same: build something that works, ship it, improve it based on what breaks. I did not know the phrase "release early, release often" yet, but I was living it.
The GM and the outgoing Technical Manager at ICONZ recognised that experience in ten minutes. Not because my CV was impressive. Because I described building things with the same tools they were using to run a national ISP.
From Europe to Aotearoa: A Different Scale, the Same Problem
Moving from Austria to New Zealand at the end of 1996 meant moving from a dense European tech ecosystem to something smaller, more concentrated, and more resourceful.
In Europe, Novell was still dominant in networking. The web was growing but had not yet consumed everything. My university work on AI prototypes using GNU tools and my freelance web development existed in an environment with many options, many competing vendors, and a large talent pool.
New Zealand in 1996 was different in scale but not in ambition. The country had embraced the internet early. Internet uptake was among the highest in the world, growing at roughly 15 percent per month [5]. Telecom had launched XTRA in May 1996, bringing serious corporate resources into a market that had been built by garage entrepreneurs [5]. The competition was intensifying.
What New Zealand lacked in scale, it compensated for in necessity. A small ISP in Auckland could not hire a team of Solaris administrators and a separate team of network engineers and a separate team of web developers. It needed people who could do all of it: people who had built things themselves, understood the full stack, and could troubleshoot under pressure without calling a vendor support line.
These early days were extraordinary. Using Linux to run an ISP was mind-boggling to me. The operating system I had discovered through a magazine two years earlier was now the engine behind a national internet provider. The 28-hour kernel compile on my 486 in 1994 felt like a personal experiment. Walking into ICONZ in 1997 and seeing Linux running mail servers, web servers, and DNS for thousands of customers felt like confirmation that the experiment had been right all along.
I had backed the right horse. I had just not realised how fast it was running.
Building the NOG and the Help Desk
My responsibilities at ICONZ went beyond keeping the servers running.
I became a founder of the New Zealand Network Operators Group (NZ NOG). Network operators groups are where ISPs, telcos, and infrastructure providers share operational knowledge, coordinate peering arrangements, and solve the collective problems that no single provider can address alone. In a small market like New Zealand, where a handful of providers carried the country's entire internet traffic, this kind of cooperation was not optional. It was the only way the infrastructure worked.
The help desk was a different kind of challenge. Fifteen support people handling customer queries for a service that most of those customers barely understood. The internet in 1996 was new to most New Zealanders. Modems needed configuring. Email clients needed setting up. Connections dropped and nobody knew why. Our help desk won awards for customer service, not because we had better tools than anyone else, but because we had people who understood the technology well enough to explain it simply.
Technical budgets, staff appraisals, professional development, product development. The role was everything at once. In a startup ISP running on Linux, there was no separation between the person who planned the network and the person who crawled under a desk to replace a cable. That was the job. That was why ten minutes of conversation was enough to know whether someone could do it.
The Modern Bridge: Pattern Recognition in the AI Era
That ten-minute interview in 1996 was not reckless. It was pattern recognition.
The GM and the outgoing Technical Manager were not looking for credentials. They were looking for evidence that I had already solved the kind of problems they faced. Can you build and run Linux infrastructure? Have you done it before? Can you think on your feet when something breaks at 3 a.m.?
The same pattern recognition is playing out now in hiring for AI roles. The most valuable people in AI-integrated organisations are not necessarily those with the most impressive qualifications. They are the people who have already used LLMs to solve real problems, who have built prompts, tested outputs, identified failure modes, and developed workflows that produce reliable results.
The ten-minute test still works. Show me what you have built. Tell me what broke. Explain how you fixed it. If the answers demonstrate genuine experience, no amount of panel interviews will tell you more.
The toolchain changes. The principle does not. In 1996, the question was: can you make Linux serve a country's internet traffic? In 2026, the question is: can you make AI systems work reliably and transparently within the governance frameworks your organisation requires?
The people who can answer "yes" with evidence will always be hired faster than the people who can only answer with qualifications.
Your Ten-Minute Moment
Have you been hired, or hired someone, based on gut instinct about technical depth?
Have you recognised a colleague's competence from a brief conversation, long before any formal assessment confirmed it?
Have you been the person who walked into an unfamiliar environment and immediately knew you could contribute, because the problems matched the skills you had built through practice?
Share your ten-minute moment. The best hiring decisions are rarely made by committee. They are made by people who recognise competence because they have lived it themselves.
Next in this series: Episode 5, "Linux.co.nz and a Number Plate: Betting on the Future"
References
[1] Wikipedia, "ICONZ," https://en.wikipedia.org/wiki/ICONZ. Corroborated by InternetNZ nethistory project.
[2] Keith Newman, "Connecting the Clouds," nethistory.co.nz, Chapter 7, https://www.nethistory.co.nz/Chapter_7_-_Craving_for_Connection_II/
[3] "Internet in New Zealand Timeline," nethistory.co.nz, https://www.nethistory.co.nz/Internet_in_New_Zealand_Timeline/. "More than 160,000 users" cited for 1996.
[4] Wikipedia, "Linux kernel version history," https://en.wikipedia.org/wiki/Linux_kernel. Kernel 2.0 released June 1996, first release with symmetric multiprocessing support.
[5] "Down to the Wire: 1996," downtothewire.co.nz, https://downtothewire.co.nz/1996/index.html. Internet uptake growth and Telecom XTRA launch.
[6] Personal testimony and briefing documents. Direct source for interview details, ICONZ role, NZ NOG founding, help desk awards, European web development.
[7] Wikipedia, "ICONZ" (co-founders). Jon Clarke and Chris Thorpe co-founded ICONZ; Clarke (technical), Thorpe (marketing/business). Note: some sources attribute Craig Whitmore as early technical manager.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at linux@linux.co.nz.
A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era.
I acknowledge the role of AI tools, such as Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, which assisted in drafting, editing and reviewing. They accelerated the process, but the first draft, revisions, vision, voice and final decisions were mine alone.