Embracing Her Critics To Refine VoIP

Engineer Marian Croak wanted to be able to fix things since she was a child, and a decades-long career at AT&T Bell Laboratories and Google provided ample opportunities to do so. A prolific inventor in the field of voice and data communication, Croak is best known for her work on Voice over Internet Protocol (VoIP), which she helped develop into the ubiquitous technology we all use to make calls over the Internet.

You began your career in the Bell Labs Human Factors division before moving on to a network engineering role. How did you come to work on VoIP?

First of all, I want the world to understand that I did not invent VoIP. It’s an international standard, and as companies—usually much smaller companies—tried to implement it, they were running into enormous difficulties around reliability, quality, and scale. Calls would drop, or they would be very choppy. I wanted to do two things: first, to convince AT&T that VoIP was going to be very important, and second, to get them to consider using it as their main voice network.

At the time, AT&T was the largest telecommunications company in the world, and it was in the midst of upgrading its dedicated analog network.

That network was designed to be as close to perfection as you can imagine. It achieved five-nines reliability, meaning only five minutes of downtime throughout a year. However, when I joined the company, a lot of the components were aging out, so they were working on a new packetized protocol. This protocol offered extremely good quality, but it was highly proprietary, and you would need new equipment to use it. The equipment was expensive, and it was not ubiquitous like the Internet was at the time.

But, you know, it was almost a joke for me to propose using VoIP. People said, “Are you kidding? VoIP is a toy. You’ll never get it to scale to support business-grade service.” Yet I believed that, with the small group of developers I had in my team, we could perfect it. No-one told me no; they just said, “Go off in your lab and work on it.” I think they were trying to placate me.

Soon, though, you were able to solve a lot of the most troublesome issues with the technology.

It took us about a year and a half, but we solved a lot of problems around reliability and voice quality. We worked quickly, and we piloted our work with business customers to iterate and make it better. There was a lot of experimentation, and many of the patents you see in my name are a result of failures we were able to fix—inventions that helped detect call failures, process signals, and address other issues.

At the same time, there was this enormous team in AT&T that worked on the “true” voice network. They were slow, but like I said, they achieved perfection, so they had an awful lot of knowledge. However, as you can imagine, having our little team working in parallel was a bit threatening to them, especially when I would make presentations about the fact that VoIP was becoming more ubiquitous and, even though it was still creaky, the possibilities were there.

I suppose it makes sense that you, as a relative newcomer, were better positioned to see VoIP’s potential than people who’d spent their careers working on the classic network. How did you go about convincing others?

I developed very thick skin during that time. Not only were the core network people upset with me, the executives had also invested billions of dollars in building this new protocol, and they were very skeptical—as they should have been. Fortunately, a few senior leaders were quite creative in their thinking, and they gave me the encouragement that I needed to keep going. And after we demonstrated our work, I think people understood what was happening.

You’ve written before about the need to embrace your critics. Can you give me an example from that time?

At first, it felt humiliating to hear people say, “I think you’re crazy,” or, “This is just not going to happen.” Then, I began to embrace what they were saying, and I realized they were right—we did have to be able to achieve at least four-nines, if not five-nines, reliability, and we did have to make sure we could reroute calls around traffic congestion and so on. So instead of taking the criticism harshly, we started to accept it, and incorporating it made our work better.

That’s interesting. I guess I didn’t expect you to provide such a far-reaching answer, because there are certainly plenty of times when incorporating a piece of feedback can help improve, say, the design of a project or specific lines of code. To hear someone say they disagree with the fundamental premise of your work and react with an open mind—that must have been quite difficult!

Well, I had to grow into that. But it was tremendously helpful in terms of understanding our next steps. When I started listening to what my critics were actually saying, I thought, “Okay, then that’s what we’re going to do, right? Thank you for letting me know.”

Your work on VoIP spanned many years and hundreds of patents. Aside from the big-picture vision, what accomplishments are you most proud of?

One of the things I really enjoyed is giving users control over the signaling network. Before, if you wanted to have a third-party call or send different signals to the network—like, if the line is busy, send it to voicemail—you had to do it through the network provider, and it would cost you money. It was nice to be able to design things so that the user could have immediate control over what they wanted to do, which is even more ubiquitous today.

You spent more than 30 years at AT&T before joining Google in 2014. Can you talk about your time at Google?

What drew me to Google was the desire to do something that would help the world, because they offered me a position to bring Internet to emerging markets in India, Southeast Asia, and Africa. Part of the motivation was to stimulate the market so that local people and businesses could get online and build whatever the local economy could afford.

In India, for example, they had the foresight to build fiber along the railroad system. So the essence of the infrastructure was there, and we put up Wi-Fi stations that enabled people to come to the railroad and do their homework or just use the Internet. In Africa, they needed help building the middle mile for fiber. They already had the last mile, and they had cable systems coming in, but the middle mile was missing. So the work we did depended on what was needed in the region.

You’ve also done work at Google in a more familiar space, namely reliability engineering.

I supported the Ads business, YouTube, and our internal network and tools. It was fascinating to learn about all those different businesses, and in particular to understand how to measure reliability from a user’s point of view rather than a systems point of view. System components can work perfectly, but if users aren’t getting the experience that they need, then something’s failed. So we began measuring it in terms of the minutes of good versus bad experiences on a typical month or week or day.

And now you lead a team that’s focused on human-centered AI and foundational Machine Learning.

We also look at things from the end users’ point of view and try to understand user intentions—whether they’re satisfied by the responses to whatever prompts they give AI systems or models.

Some of that work centers around making sure the systems are providing the right information and are doing so in a way that is sensitive to cultural nuance. Other times, we look at how users rate their experience. Are they paying attention and going deeper or are they moving on to something else very quickly?

I suppose that work must also come with its own reliability issues.

I think what most providers are grappling with now is eliminating hallucinations, which is definitely part of reliability. There are many, many people at Google working on this problem, but the way that I approach it is to say, the more high-quality information which is not yet on the Internet that we can incorporate in our training model—the more we can get right.