What Event Networks Teach You About Failure
Failure behaves differently when a network is temporary.
In a permanent office, an imperfect configuration can survive for months. A weak wireless zone becomes “that corner where the Wi-Fi is weird.” An overloaded switch earns a ticket, gets discussed in a meeting, and eventually lands on a maintenance calendar.
An event network has no such patience. The doors open at a fixed time. Attendees arrive in waves. Presenters start streaming. Exhibitors begin processing payments. A network that was handling a few dozen technicians suddenly has to support thousands of devices belonging to people who have never connected before.
Glenn has spent much of his career working inside that compressed timeline. He has built temporary infrastructure in convention centers, hotel ballrooms, skyscrapers, open spaces, and international tournament venues. Some builds have required an entire network to be installed, tested, operated, and removed within little more than a day.
That environment teaches a harsh but useful lesson: failure is rarely caused by one dramatic mistake. It usually begins with a small assumption that nobody tested.
The deadline does not care about the network
The defining feature of event networking is not the number of switches or access points. It is the immovable deadline.
A corporate migration can be postponed. A product launch, keynote, livestream, or esports match usually cannot. When the doors open, the network is either ready or it is not.
That changes how engineers plan. There is less room for experimentation once the build begins. Hardware must be familiar. Configurations should be reusable. Responsibilities need to be understood before the team arrives.
Glenn’s preference for simple, rugged systems comes directly from this reality. Complexity may look sophisticated in a diagram, but every extra dependency creates another thing that can fail under pressure. His event teams rely on repeatable processes because the venue itself already provides enough surprises.
This is not limited to temporary deployments. Any organization preparing a major migration, office opening, or customer-facing launch can benefit from treating the deadline like an event opening. Decide what absolutely must work, reduce unnecessary variables, and test the recovery plan before the real audience arrives.
The venue is part of the system
Network diagrams tend to make infrastructure look clean. Boxes connect to lines. Lines connect to other boxes. The physical building disappears.
Event work makes that illusion impossible.
Elevator access can delay equipment. Concrete, steel, glass, temporary walls, lighting rigs, cameras, and competing wireless systems all affect the final design. A cable path that looked simple during planning may become unusable once staging equipment arrives. An access point may be perfectly configured but badly positioned after a booth or video wall changes the RF environment.
Cisco’s current design guidance for large public networks emphasizes that event environments must accommodate frequent client movement, unpredictable device types, high-density usage, interference, and temporary infrastructure that may exist only for a particular show.
The practical lesson is straightforward: infrastructure does not operate in an abstract layer. It operates in a room, building, venue, or field. Engineers need to walk the space, understand who else is using it, and confirm that the physical plan still matches reality.
Capacity is not the same as readiness
A network may have plenty of bandwidth and still fail badly.
Thousands of devices can arrive within minutes. They request addresses, authenticate, roam between access points, begin cloud backups, download updates, and search for the strongest signal. Meanwhile, exhibitors are running payment systems, presenters are streaming video, and production crews are moving large files.
Large public venues must account for connection density, roaming behavior, address allocation, radio interference, segmentation, and the capacity of supporting tables and controllers, not simply the speed of the internet connection.
Event networks expose the difference between theoretical capacity and usable capacity. A fast uplink means little if DHCP is exhausted, authentication is slow, or too many devices compete for the same channel.
For permanent IT teams, this is a useful reason to test sudden demand rather than relying on average utilization. Most failures happen during peaks, not during a quiet Wednesday afternoon.
Temporary networks punish undocumented dependencies
One of the worst phrases during a live build is, “I thought that was handled by someone else.”
Event infrastructure crosses organizational boundaries. The venue owns part of the network. A service provider owns another part. Production teams, exhibitors, security contractors, payment vendors, and streaming crews each introduce their own systems.
The network team may technically control only a fraction of the path while still being blamed for anything that fails along it.
This is why ownership needs to be explicit. Every circuit, handoff, VLAN, cable run, support contact, and escalation path should have a named owner. If a critical connection depends on a third party, that relationship needs to be tested while everyone is still available.
NIST contingency guidance similarly treats recovery as a coordinated combination of plans, people, technical measures, vendor contacts, backup capabilities, and tested procedures. Redundancy alone is not enough if nobody knows who is responsible for activating it.
Redundancy has to be usable
Engineers love saying a system is redundant. The word looks reassuring in proposals.
The harder question is whether the backup path will work under real conditions.
Does it have enough capacity? Does it depend on the same conduit, power supply, carrier, or configuration as the primary path? Can the team switch to it quickly? Has anyone tested it since the last change?
A backup connection that has never carried realistic traffic is still a theory.
Event networks force teams to think about recovery in practical terms. The objective is not merely to own spare hardware. The objective is to restore service before the audience notices.
What permanent networks can learn from temporary ones
Event networking magnifies ordinary infrastructure problems. That makes it useful far beyond the events industry.
The lessons are simple:
Build around the deadline that actually matters.
Reduce unnecessary dependencies.
Test the physical environment, not just the diagram.
Plan for peak behavior instead of average traffic.
Assign ownership before something fails.
Test backups under realistic load.
Keep the recovery procedure simple enough to use while tired.
A temporary network has nowhere to hide its weaknesses. That is precisely why it can teach permanent IT teams so much.