Building a Global Livestream in Seven Days
At Research Now (later Dynata), leadership needed to deliver a confidential acquisition announcement to more than 1,200 employees across North America and Europe. They also wanted to include offices in Asia-Pacific, even if that meant employees in Australia waking up in the middle of the night.
Normally, executives traveled to different regions to deliver important company announcements in person. But this announcement had strict legal requirements around how the information could be communicated, and the usual approach wasn’t going to work.
I suggested livestreaming the announcement so employees could hear directly from leadership, wherever they were.
There was just one problem. We’d never done anything like that before.
And we had seven days. Calendar days. Not business days.
Project Snapshot
Company: Research Now (later Dynata)
Audience: More than 1,200 employees, with Asia-Pacific offices also included
Timeline: Seven calendar days
My role: Proposed the livestream, researched and designed the production setup, developed and tested fallback options; co-ran the broadcast with my boss
IT support: Application support team established a workable internet connection
Recognition: CEO Award
Understanding What the Production Needed
Our all-hands meetings took place in a movie theater. The CEO wanted to deliver his presentation on the big screen, then switch to a live camera feed whenever he wasn’t showing slides.
That was straightforward enough for the people sitting in the theater. But now I needed to produce the same event for employees watching through WebEx, with a slightly different viewing experience. I wanted remote employees to see both the speaker and the presentation in a picture-in-picture format.
WebEx could connect to a webcam, but the theater production required a professional camera. That camera could connect to the movie projector, but it couldn’t connect directly to WebEx.
Then there was the audio. We couldn’t tap into the theater’s existing sound system, which meant I needed to mic the speaker for both the room and the remote broadcast. Getting sound to both audiences without creating feedback was another problem to solve.
I had multiple sources that needed to go to different destinations, and I needed control over what each audience saw and heard.
The equipment existed to accomplish those things individually. I needed to figure out how to make it work together.
The First Decision: Build It or Bring Someone In?
I was given what was described as an “unlimited” budget. Given the importance of the announcement, leadership was prepared to invest in getting it right.
My boss and my boss’s boss made it possible for me to take on a project this ambitious. They said they trusted me, and they acted on that trust. I had room to research the options and make decisions without having to justify every experiment before I could try it.
My first step was to look into professional livestreaming companies. Their services were expensive, but the cost wasn’t ultimately what ruled them out. I couldn’t find a company that could take on the production with only seven days’ notice.
That settled the question. I would have to build the system myself.
I researched video switchers and equipment that could convert professional camera signals into a format suitable for livestreaming. I ordered a switcher and a device advertised as a livestreaming encoder. The specifications sounded promising, but I still needed to test whether the equipment would actually work with WebEx.
Start With What Works
I had to be realistic about what I could accomplish in seven days.
The ideal production would give both audiences a professional viewing experience. I’d be able to switch between the presentation and the camera in the theater, while remote employees watched the speaker alongside the slides.
But the minimum requirement was much simpler: everyone needed to be able to see and hear the announcement at the same time.
I knew there were ways to accomplish that, even if they weren’t pretty. So I started with the things I knew would work and built from there.
As I experimented, I found solutions that handled one part of the production but created limitations somewhere else. A connection might give me the video I needed but not the audio. Another approach might work for WebEx without giving me enough control over what appeared in the theater.
I didn’t throw those solutions away just because they weren’t ideal.
I kept track of what each arrangement could accomplish and where it fell short. Some became useful alternatives if a more complicated part of the production failed.
That gave me a way to keep improving the broadcast without risking the basic requirement. I could pursue a better production knowing I had simpler options to fall back on.
Building a Test Environment
I didn’t want to discover the limitations of my setup for the first time in a movie theater full of executives.
I took over a conference room and recreated the basic production environment. A television stood in for the theater projector. I used a laptop to run WebEx and another to represent someone watching remotely.
That gave me a way to experiment with the equipment and see what each audience would experience.
The setup went through a lot of iterations. I tested different ways of routing the video feeds and worked through how to manage the presentation without losing the camera feed. Screen sharing became an important part of the solution, and multiple WebEx sessions gave me options that a single connection couldn’t provide.
I remember the eventual setup involved two computers running presentation materials, with one providing a monitor for the speaker. My Mac Pro tower handled the main video and audio production, and another laptop ran WebEx.
I couldn’t recreate the exact wiring diagram from memory today. There were a lot of connections and more than a few experiments along the way. In fact, I may still have the original technical drawing somewhere.
What I do remember is that I wasn’t testing just one configuration until it worked. I was learning which parts worked reliably, which ones caused problems, and what I could use instead.
By the time I moved the equipment into the theater, I had a working production setup and fallback options for some of the things that could go wrong.
Getting Everything Into the Theater
The theater introduced a couple of challenges of its own.
First, it didn’t have an internet connection.
I worked with our IT application support team to solve that problem. They provided their best wireless hotspot, but the signal wouldn’t stay reliable inside the theater. After testing different locations, we found that placing the receiver just outside an exit door gave us a workable connection.
It wasn’t an ideal networking arrangement, but it gave us the connectivity we needed for the broadcast.
The physical distance between the production equipment and the theater projector was another consideration.
My switcher could feed the projector through HDMI, but a standard cable couldn’t reliably carry the signal that far. I had to source a specialized long-distance HDMI cable to make the connection.
The production equipment was set up at the front of the theater. My boss and I ran the broadcast together from there.
By this point, I had spent days researching equipment and working through problems I’d never had to solve before. I was learning a great deal about the limitations of software and hardware that hadn’t been designed to work together this way.
But I had built a setup that could meet the production requirements, along with a better understanding of what I could do if part of it failed.
Five Minutes Before the Doors Opened
And then the audio stopped working.
Of course it did.
We were minutes away from the announcement. The executives were ready, employees in other offices were preparing to join, and there wasn’t time to pull apart the production setup to figure out exactly what had happened.
Fortunately, I already had an alternative.
During testing, I’d worked out that a separate WebEx connection could carry the audio if I needed it. It wasn’t my preferred solution, because the video and audio would be way out of sync. But it would allow the remote audience to hear the announcement.
I brought in another laptop and used an additional WebEx login to carry the audio separately from the video feed.
It was one of the compromises I’d already considered, and I knew what I was giving up by using it.
Five minutes before the doors opened, I wasn’t trying to make the broadcast perfect. I needed to protect the one requirement that had been there from the beginning: employees had to be able to see and hear the announcement.
And they could.
The announcement went out.
What Came After
That first broadcast was built around a very specific deadline. But it also established something we hadn’t had before: a way for leadership to communicate live with employees across multiple regions.
The process continued to develop after that initial event.
Over time, I refined the production workflow and worked with more capable broadcast equipment, including a NewTek TriCaster. The company used live broadcasts for regular executive communications and quarterly updates. Some meetings required multiple sessions to accommodate employees in different time zones.
We also had a process for recording events and making replays available to employees who couldn’t attend live.
My work extended beyond operating the broadcast equipment. I supported executive presentations and helped prepare speakers for these events. The experience became part of a broader role supporting leadership communications, including executive committee and Board presentations.
But that first broadcast was different. There was no established process, no previous event to use as a reference, and very little time to work out the details.
I had to figure out what was possible and then make it happen.
Why I Remember This One
The idea to livestream the announcement was mine, and I volunteered to make it happen without an existing process to follow. I used every possible moment I could. It was the first time I looked at the floor of the conference room at 3 am in the morning and thought, “I could sleep there but would I get in the way of the cleaning crew?” The nights were long. But I did it and I’m still proud of what I accomplished without AI, without the tech advances there is today. That matters to me as much as the technical problem-solving.
There’s another reason this project means so much to me. My boss and my boss’s boss were two of the most supportive people I’ve ever worked with. They gave me room to explore and grow, and my boss was right there with me running the first broadcast. Their support went beyond this project, and even beyond work. They supported me personally, too. I’ve never forgotten that, and I’m incredibly thankful for both of them.
The CEO gave me the CEO Award for the work. I was proud of the recognition, of course. But I was just as proud of what happened five minutes before the doors opened. When the audio failed, I didn’t have to start from scratch. I’d already tested a separate WebEx connection as a fallback, and I knew its limitations. The broadcast wasn’t going to be perfect, but everyone would still see and hear the announcement. That was the requirement I’d built the entire plan around.
Seven days. Very long cables. One extra WebEx login at exactly the right moment.
Not the prettiest first broadcast. Definitely one of the most satisfying.
