Skip to content
Tech Operations

Keeping 55,000 People Online at COP-29: Inside the ICT Team

4 min read771 wordsUpdated Apr 24, 2026

I was selected as 1 of 50 ICT technicians from ~15,000 applicants to support COP-29 in Baku — the 29th UN Framework Convention on Climate Change conference — tracking 1,000+ laptops, setting up presentation equipment, and responding to AV incidents in real time for a 55,000-attendee event. This is the post about the operational side of COP-29, why conference-scale IT is its own discipline, and what the experience taught me that compounds back into engineering work.

TL;DR

  • Selection: 1 of ~50 ICT technicians from ~15,000 applicants.
  • Event: COP-29, 55,000 attendees, Baku, November 2024.
  • Responsibilities: fleet tracking on 1,000+ laptops, presentation AV, daily patches, cross-shift memos.
  • Lesson that scales: operational discipline is the real product — runbooks, handoffs, and pre-agreed playbooks.

What COP-29 is

COP-29 is the 29th meeting of the Conference of the Parties to the UN Framework Convention on Climate Change. It's the yearly event where national delegations negotiate climate policy. In 2024 it was in Baku, Azerbaijan, November 11–22. 55,000 attendees across delegates, observers, press, and visitors. Dozens of venues, thousands of sessions, three official languages plus interpretation into many more.

The ICT team is the layer of people who make sure all of that technology runs every hour of every day.

How selective the team was

~15,000 applicants, ~50 ICT technicians selected. The selection weighted:

| Factor | Why | |---|---| | Technical fundamentals | Fix problems without a supervisor present | | Prior ops / event experience | Thrive under simultaneous incidents | | Languages (English / Russian / Azerbaijani) | International delegate coverage | | Calm under pressure | Obvious, but selected for specifically |

Getting the call was one of the more humbling moments of 2024 for me.

What the day looked like

A typical day on shift ran something like this:

  1. Morning memo — daily patch list and assigned meeting rooms, handed off from the outgoing shift.
  2. Presentation setup — checking laptops, projectors, microphones, video walls in assigned rooms before sessions.
  3. Session support — on-call inside rooms. If a presenter's laptop crashed, if a dongle failed, if a broadcast feed dropped, you had minutes, not hours.
  4. Fleet tracking — sign-in/sign-out on the laptops assigned to the day's rooms and presenters. 1,000+ devices moving across a venue is a logistics problem, not a tech problem.
  5. End-of-shift handoff — written memo to the incoming team. Assumes nothing.

Tracking 1,000+ laptops

Asset-tagging on intake, with:

  • Serial number.
  • Assigned user / presenter.
  • Assigned meeting room.
  • Patch window.

Every day, every device was checked in and out against the inventory. Any device that missed its patch window got flagged and tracked the same day — a single misbehaving laptop in the wrong room is a very loud failure at a UN conference.

Incident response in live sessions

The unwritten rule: operate assuming something will fail every hour. Your playbook is agreed in advance with AV, broadcast, and session management so nobody is waiting for authority when a crisis hits a live session.

Common incidents:

  • Presenter laptops locking up mid-slide-deck.
  • Dongles or HDMI adapters failing.
  • Microphones picking up buzz from a faulty cable.
  • Network saturation in specific halls during high-profile sessions.
  • Interpretation feeds dropping.

You carry spares for everything you can, and you have a human-scale plan for everything you can't.

What I took from it

| COP-29 lesson | How it maps to engineering work | |---|---| | Runbooks that hold up when you're tired | Production runbooks, on-call discipline | | Clear handoffs across shifts / time zones | Async comms, PR descriptions, alert routing | | Pre-agreed playbooks across functions | Incident response that doesn't stall on authority | | Owning a problem across a shift boundary | Owning a bug until it's resolved, not handed off |

These translate cleanly from running conference IT to running AI-infra on-call or leading a student mentorship program. Operational discipline is the real product. The tech is almost incidental.

Background / resume context

This work is listed on my about page and projects page. COP-29 was one of several on-the-ground ops experiences I leaned on later when building large-event-scale software — including multi-agent simulations for Adneural and SSH hosting for TerminalTUI, both of which are, at their core, "what do you do when things keep moving without you."

Key takeaways

  • ICT at UN scale is an operations discipline first, a technology discipline second.
  • Pre-agreed playbooks + written handoffs are what make a 55,000-attendee event look effortless from the outside.
  • The selection-rate story is worth remembering: 50 out of ~15,000. Getting chosen was a crash course in what elite ops teams look like.

References

Frequently Asked Questions

What does an ICT technician do at a UN climate conference?

You keep 55,000 attendees, thousands of delegates, hundreds of broadcasters, and the presentation infrastructure working, continuously, for two weeks. The day-to-day is a mix of fleet management (tracking and patching 1,000+ laptops), presentation-equipment setup in meeting rooms, rapid incident response for AV failures during sessions, and coordinating daily handoffs across shifts.

How selective was COP-29 ICT team recruitment?

For COP-29 in Baku, about 50 ICT technicians were selected from roughly 15,000 applicants. The selection weighted technical fundamentals, prior large-event or ops experience, and English/Russian/Azerbaijani language coverage because of the international delegate mix.

How do you track 1,000+ laptops across a venue?

Asset-tag every device on intake with a serial + assigned user + assigned meeting room. Check-in/check-out per day in an inventory sheet. Patch cycles are centralized. Any device that misses a patch window gets flagged and tracked down the same day — because a single misbehaving laptop in a keynote room is a very loud failure.

What goes wrong at a 55,000-attendee conference?

Presenter laptops, dongles, mics, and video walls fail in the middle of sessions, in every possible combination, at the worst possible moment. Network saturation in specific halls during high-profile sessions. Language-interpretation feeds dropping. You operate assuming something will fail every hour, and your playbook is pre-agreed with AV, broadcast, and session management so nobody's waiting for authority to act.

What did you take from COP-29 into AI/engineering work?

Operational discipline. Writing runbooks that hold up when you're tired. Communicating across functions and languages quickly. Owning a handoff. Every technical lesson from building software scales down to a three-person standup — what you learn at 55,000-attendee scale is the coordination itself.

cop29unfcccconference-itictazerbaijanvolunteerlarge-scale-eventsnetwork-operations