Right now, so much of what
is going on in the industry
is driven by the values of scale and speed.
It is about maximizing growth.
It is about maximizing connectivity.
What about thinking about what
we're losing in those values.
There's nothing wrong with growth,
but not at the expense of humanity.
>> Hi, everyone.
Welcome to Behind the Tech.
I'm your host, Kevin Scott,
Chief Technology Officer for Microsoft.
In this podcast, we're going to get
behind the tech.
We'll talk with some of the people who have
made our modern tech world possible
and understand what motivated them to
create what they did.
So, join me to maybe learn a little bit about
the history of computing, and get a few
behind-the-scenes insights into what's happening today.
Stick around.
(music)
Today, I'm joined by my colleague, Christina Warren.
Christina is a senior cloud developer advocate
at Microsoft.
Welcome back, Christina.
>>Hey, Kevin. Great to be here again.
>>So, we are going to talk with Judy Estrin today.
And I have been super excited to get this interview
on the books, because Judy is truly one of the most
amazing individuals in tech who I've ever met.
>>Yeah. Just seeing how far back her association
with the Internet goes, and all the different roles
that she's had as an engineer and as an entrepreneur.
>>Yeah, her story is incredible.
Like the fact that it starts with amazing anecdotes
like her dad working for John Von Neumann
at the Institute for Advanced Study.
And sort of goes all the way through
her direct involvement in the creation of
the Internet protocols, to illustrious career in
the technology industry as an executive and board member.
I mean, just incredible stuff.
>>I'm really looking forward
to hearing what you two discuss.
>>Awesome. Well, thanks for chatting, Christina.
We'll catch up later in the show.
>>Talk soon.
(music)
Coming up next, Judy Estrin.
Internet pioneer, entrepreneur,
tech executive,
author of the book Closing the Innovation Gap,
and one of the most incisive thinkers on the intersection
of the Internet, democracy, and humanity.
So, welcome, Judy.
>>It's a pleasure to be here.
>>Oh, awesome, awesome.
I've been so looking forward to chatting with you.
So, I wanted to start with your childhood
because you had this amazing career
in technology, and your father is a very well-known
computer scientist.
So, with you, it started especially early. Right?
>>Yeah. I had the advantage of being a second-generation
technologist when computers didn't really exist.
But it wasn't just my father.
it was my father and my mother.
My father worked with Von Neumann on the
part of the team at
the Institute for Advanced Sciences
on the first computer.
He and my mom were then invited to go to Israel
to help lead the team that built the first computer
in the Middle East, the WEIZAC.
They then ultimately came back and came to California
and my dad started the computer science department
at UCLA, and was there for years.
My mother also has a PhD in electrical engineering.
And when she got her PhD from Wisconsin,
there was one other woman in the country who got a PhD
in electrical engineering that year.
>>Wow.
>>At least that was the story in our family. And so --
>>And when was that?
>>It was in the late '40s.
An interesting story.
When they came to UCLA, she could not work in the
engineering department, where my dad was
because of nepotism rules.
And so she ended up starting a data processing lab
in the Brain Research Institute at UCLA.
So, she was one of the first biomedical engineers
and really excelled and helped build that field.
So, I had two unbelievable role models.
And lots of positive aspects to that.
>>And I'm guessing there's some intimidation, too,
as well.
>>Some intimidation.
I can still remember in high school when my dad
brought home some video tapes to learn Fortran.
And my dad ended up leaving me notes in Fortran.
So, he would leave me "if, then, else" statements
of what I was supposed to do that day. (laugh)
And so it was my way to bond with my father
that I ended up probably going into computer science.
>>Well, let's talk about your mother a little bit more.
So, your dad is Gerald Estrin.
>>Right.
>>And I think I know less about your mother,
but it sounds like her career path, in many ways,
might be the most extraordinary one.
Did she share any stories with you about what it was like
to get that PhD in electrical engineering
at that point in time?
And, like, she must have had this beautiful vantage point
to sort of see how the field unfolded
over the past many decades.
>>Yeah, both of them were pioneers in their own right
and in different ways.
But one of the interesting things is that I remember
when I was younger, and people assume
that my father probably got my mother into engineering.
It actually was somewhat reversed.
I just grew up in an environment where
my parents were so equal in terms of their balance of
career and passion.
My mom was a very strong personality, very outspoken.
And so, yes, we heard a lot about how hard it was,
every step of the way, being a pioneer
as a woman in the field.
She was very involved in the IEEE.
She was always running for office in different things.
She often talked about being a woman in a man's world.
She went on to also, though be very, very involved
in organizations that would help other women.
And so whether it was the Society for Women Engineers
or Grace Hopper, started out as
the Anita Borg Institute,
she was a very strong advocate for exposing
girls and women to engineering and the sciences
and providing opportunities for them.
>>Yeah. So, it sounds like some of your first exposure
to programming were these Fortran tapes and your dad's
"if, then, else" instructions --
>>Right.
-- about chores and whatnot.
Do you remember the first program you wrote
and what it did?
>>Well, I don't know if I remember the first program.
I vividly remember --
So, at UCLA -- now, let me back up a minute.
For people who are exposed to the world today,
most people who wrote their first program, you know,
maybe it goes back to having an Apple or some kind of --
remember, there were no personal computers.
>>Yeah.
>>So, in order to write a program, you needed
access to a mainframe.
>>Yeah.
>>So, there really wasn't an opportunity to write
a program before being exposed to --
>>Yeah, and so you had to get to a terminal room --
>>Well --
>> -- probably not even a terminal room.
>>Right. Yes.
>>You were doing punch cards.
>>So, you were still doing punch cards
and batch submitting.
One of my favorite stories, and I ended up using this
in the book, is that I can still remember that I was working
on something.
I kept submitting these cards and it kept coming back
"abend" -- abnormal ending.
So, you know, the equivalent of crashing
your computer today.
And I had been up all night doing it.
I just came home in tears.
I mean, I just was so frustrated.
And my father sat me down and said,
"Take a step back. When you have a problem that you just
are overwhelmed by, try to figure out how to break it
into pieces, and how can you solve the individual pieces?
But keep in mind how all the pieces fit together."
That approach to problem solving stuck in my head
through my whole life, and not just when it comes to
writing a program. But how do you tackle
really complex problems, not going to the extreme?
And, frankly, we can talk about this if you want.
One of my problems with Agile these days is
the notion of break it into little pieces,
but not keeping the architectural piece
sometimes, of knowing how they fit together.
>>Yeah.
>>That balance of addressing complex issues by being able
to figure out pieces that you can solve
and the interconnections, that system level of thinking
was something that my dad, I think, it was so much about
his approach to life and how he saw things.
>>So, what you were just talking about,
this amazing advice that your dad gave you about
decomposing a problem is something that has come up
somewhat frequently in the conversations I have with
other computer scientists recently.
And there's this question of kids these days who are
being trained as software engineers are dealing with
such higher-level abstractions than the ones that
we were dealing with when we were up and coming
as programmers.
And the question that I hear people asking
over and over again is whether or not
they're missing something by not being exposed
to just this wide differential between
the top-level understanding of the problem and just these
absolute nitty-gritty, atomic details
of how to get a solution.
And I don't know what the answer to the question is.
I know that I learned to code on Apple IIe's and a
Radio Shack Color Computer 2,
which hooked up to a little 13-inch television.
And, subsequently, got the chance to
muck around with manufacturing equipment
that were controlled by PDP-8s and systems that
had wire-wrapped backplane buses and whatnot.
But I've never coded, you know, with punch cards.
>>Right.
>>And, you know, like, I just sort of wonder, like,
what did I miss by not having that?
>>So, I don't think it's the punch cards that you miss.
>>Yeah. (laughs)
>>Meaning, I do think you're really on to something here.
The punch cards are part of it which has to do with
a little bit of friction, a little bit of obstacle
being put in.
But let me start this off by saying, yes,
we're missing something.
But it isn't that everybody needs to go back
to doing that,
it's that we need to recognize
that there's a certain type of training
that is not happening, and figuring out
how to be additive.
The underlying thing I would say is we've lost
system thinking.
In the days when computer science was about
building systems, building infrastructure,
understanding how compilers work, how you talk
to a computer --
all of those things taught you a sense of learning
of system thinking.
And when I say system thinking,
I mean two different things:
One is how pieces are interconnected into a whole.
So, there's an architectural sense there,
as opposed to looking at things as just
individual points.
And then the second thing is thinking about
the consequences of things.
When you're building a system, you have inputs
and then a complex set of interaction that may have
different outputs, and poking it in different ways,
that unless you're thinking about systems
that are complicated, you don't think about
consequences -- intended and unintended consequences.
And so, those two things are really important.
And I think that whereas the abstraction, in some ways,
is so beneficial because, you know, I remember
writing assembly code for a PROM programmer.
That wasn't necessarily a good use of how many hours
it took to do it, or the punch cards.
But it seems to me, we have three side effects:
One is, do people know how to tackle hard problems?
Or do they only look for things that can be
easily solved?
And do we turn away or avoid or actually try to
simplify the problem to something we can solve
and then there are world problems that
get delayed?
The second is this whole thing of pieces in a whole.
And as I mentioned before, I really worry about
the extreme of everybody take a little piece
and not enough thinking about the architecture,
how they fit together, do you have a foundation
that is not brittle?
I worry about reactiveness.
But there's a third thing which is, it is so easy
to iterate on things.
We all talk about iterating, iterating, iterating.
So, what happens is that you don't take as much time
to think about what you're doing.
And that's one of the things, the batch cards,
it wasn't so easy to do a turnaround and try again,
and so, you thought a little bit more about how
you were fixing it before you submitted the cards.
>>Yeah.
>>When you have very rapid iteration, on one hand it is --
we all know this, it's wonderful.
You can fix problems quickly.
You can do A/B testing.
It also makes you sloppy in your thinking at times or --
I shouldn't say "sloppy" -- lazy.
We don't have to put the same amount of thought into it,
and if you're talking about failure that is
not just inconvenient, but can be harmful,
you can't just say, "Oops." Right?
So, whether it is a self-driving car that hits somebody
or a social media system whose implications is
threatening democracy,
we're not allowed to just say, "Oops."
We have to be thinking about the consequences of the
technologies that we are bringing to market,
because we are now in the center of
everything in our lives.
>>Yeah.
>>And I just am concerned that as that happened,
as we became more and more consequential to the world,
we also have not been training ourselves
or training new engineers and computer scientists
to think about those systems and consequences
in the same way.
>>Yeah.
>>And, actually, the culture is in the other direction, which is
move faster, get out a minimal viable product,
get out your feature,
and then we'll learn from our mistakes.
I'm a big believer in learning from mistakes
and learning from failure and taking risks,
but we need to take a step back and say,
"What are those risks?"
"What are the consequences of the risks?"
>>Yeah. You know, I couldn't agree with you more.
I think there were a bunch of really powerful points
you made there.
Like, sometimes the struggle, itself, like having to
sort of slow down and think about something holistically,
really sharpens your thinking.
And some of the most interesting breakthroughs
happen that way.
I remember being irritated when I was a senior
in high school taking my first real
computer science class at my professor,
who made us write the solutions to our programming
assignments down on paper before we typed them
into the computer.
And he could tell if you typed the thing
into the computer and done this iterative debug cycle
to try to get it right.
And I didn't appreciate at the time what
slowing down was doing to help me be a better thinker
about what it was that I was doing.
And then your whole point about this sort of crossing
of these two curves --
the importance of technology and its ubiquity
in our day-to-day lives. At the same time where
we're sort of more fragmented in the way that we do
software development.
We've "atomized" things into a bunch of different pieces.
Which, on the one hand, you've got to have
some mechanism to deal with complexity,
but just because you're trying to solve a complex problem
doesn't absolve you of the responsibility
of having to think very carefully about
the problem and its second-order effects.
>>So, I bring up these issues to say what we need to do is
shift our values or remind ourselves of the values
that drive that talent.
Right now, so much of what is going on in the industry
is driven by the values of scale and speed.
It is about maximizing growth.
It is about -- even in some ways,
which it sounds like a good value,
maximizing connectivity.
What about thinking about what we're losing
in those values.
There's nothing wrong with growth,
but not at the expense of humanity.
Not at the expense of society.
It might be nice to think that maximum flat,
borderless connectivity should be a goal,
but if you actually look at the way humans act
and understand a little bit more about people,
you might say, "You know what?
With connectivity needs to be some containment."
Look what happens when we build fast in Houston
and don't think about how waters move
and a hurricane comes and the floods were way worse
because we built for scale and we didn't pay attention
to containment.
When you're fighting a wildfire,
you think about containment.
Well, misinformation spreads if you have maximum
connectivity without thinking about
where you need to contain,
because bad things can happen.
So, our industry is filled with so many talented,
wonderful people, but I think sometimes we as leaders
are pointing those people in a direction
and setting values which are not, in the end,
changing the world for good.
>>Yeah. So, I want to dig in more
on this whole notion of values, but through the lens of
some of your early experience.
So, you were present at the literal creation
of the modern Internet.
So, tell us a little bit about that story, like how --
after you graduated UCLA.
>>Right. So, it goes back a little bit more in that, again,
my dad was chairman for a time
at the computer science department at UCLA.
And actually, UCLA and Stanford compete
for where the Internet began,
because one of the initial ARPANET nodes
was at UCLA.
Paul Baran, who's the father of packet switching,
was one of my dad's PhD students.
And so, again, by osmosis, I'm being exposed to this.
The other person who was one of my dad's PhD students
was Vint Cerf, who is known as the father of the Internet.
So, I ended up coming to Stanford,
doing my master's, and Vint Cerf
was my advisor.
And he was leading the team that was developing
the initial TCP protocol spec.
At that time, it wasn't TCP/IP yet,
it was just TCP -- Carl Sunshine, Yogen Dalal.
There was no computer science department then.
It was EE computer engineering.
And I was one of three women
in the master's program.
They had already mapped out the initial spec for TCP,
and it was my job to do the testing
of the initial implementations.
I can still remember the basement lab
that I used to go sometimes at 3:00 in the morning
because the two sites we tested was
BBN in Boston and the University of College London.
So, we don't think of it today because one of the beauties
of the Internet is that you have
asynchronous communication.
But we would send packets, and then we would have
a teletype machine in real time to say,
"Did you get it?"
So, we had to be on the same time frame.
So, it was a pretty exciting time in terms of
being part of that.
I will say that it was also my first exposure of
people not accepting --
they didn't really want a girl joining their group.
Not all of them, not Yogen,
but there were three unnamed people in that group
that just made my life miserable for that year.
And it was, I think, my first time of
"Oh, this is what my mom's been talking about
all of the time." It was a wonderful experience.
While I was at Stanford, I built a local area network
out of these three circuit board suitcases with Z80s.
That was the very beginning of Z80 microprocessors.
And so I built this local area network.
I ended up, when I left Stanford,
my first job was at Zilog.
>>And you were on the CPU design team
for one of their microprocessors, right?
>>I was on the design team of the Z8 and Z8000.
I was part of the software group.
And, you know, now it sounds obvious,
but in those days, it was very advanced.
My boss and the people at Zilog
decided it would be good for me to be part of the group
to look at the instruction sets
from a software developer's perspective.
Nobody had ever done that before.
And actually, I suggested an instruction in the Z8000 --
>>Which one?
>>Compare string.
That nobody had ever put in a microprocessor.
I was very lucky to be in an environment of --
that notion of it's not so much interdisciplinary,
but the different perspectives and the strength of having
software and hardware designers working together.
This is one of the early examples of the abstraction
of how do you abstract,
and one of the benefits of doing it.
>>Yeah.
>>Because it just made things like that so much easier.
>>Yeah. And, you know, now it's just incredible
to think about where the abstractions are.
>>Right.
>>You can, with a few lines of code,
maybe no code at all,
you can go to a cloud provider
and click a few checkboxes
and have petabyte-scale data storage system
deployed planet wide that can do tens of millions
of transactions per second,
and build your application on top of this.
So, on the one hand, I think the abstractions are
absolutely beneficial.
You don't want everybody all the way back, you know,
at the dawn of time having to write assembly language
for their apps.
But being able to punch past those abstraction
boundaries when you need to and to be able
to think holistically about these systems
I think is still just as important as ever.
>>We do realize that there's a huge amount of power
in some of these systems that we are making --
enabling people to use who don't understand
the power of it.
There are some abstractions that maybe you shouldn't do,
because if you understand how a system works,
you understand how it can go wrong.
And then you're a little bit more careful
in terms of how you deploy it.
And we look at cars and how cars have evolved
and where you can fix things, where you can't,
and let's take self-driving cars out for a minute.
When we let somebody get behind the wheel
and yield the power of a machine that
can do wonders, and do harm, we train them.
They get a license.
We could abstract brakes and putting your foot on the gas
even more than we do, and we don't for a reason,
because there are consequences
if you don't understand a little bit about those trade-offs.
>>Yeah.
>>And so, I worry, especially with cloud computing,
that we can get to a place where that --
we unleash technology without people having to have
an understanding of the consequences.
>>Yeah.
>>And the stuff that's gone on
about facial recognition.
We really need to think about how we
communicate those implications.
>>Yeah. There's also this impetuousness
to young engineers sometimes,
where you'll just sort of disregard a bunch of learning
that other people have done, especially if it's in
the analog world, and just sort of assume
that you can do better with software.
And, sometimes, like the control systems for cars,
these things have evolved over the course of
a century, where people have iterated and
looked at the data and they understand that these things
are safer when they're implemented
in this particular way.
You know, I remember one of my bosses
told me this story.
So, he was a power systems engineer by training,
and he was telling me about Three Mile Island,
and that one of the reasons that they didn't notice
the meltdown sooner was the monitoring systems
were just too noisy.
>>Right.
>>The operator was staring at this wide, wide panel
that had dials and gauges and indicators
and flashing lights, and just sort of
missed the one important one.
And I've always thought about that
from and operations engineering perspective.
You can monitor a large-scale, distributed system
and literally have millions of instruments out there
sort of looking at everything.
But if you're not able to surface the most important
thing to folks who are going to have to fix things,
then it's all sort of pointless.
And we're having this conversation, I think,
more urgently now around AI and data.
You know, the facial recognition stuff
and bias in data sets.
I like the direction that the conversation
is proceeding in, but I think there's still
a lot more to be done.
>>Right. So, I'm not just saying this to flatter you
and because it's your podcast, but my conversations with you
on this over the last year that we've been talking about this
have given me some hope. Because I think there are
forces in the industry, some that are really just
so focused on progress at all costs,
and others that are understanding of the technology,
but are conscious of those trade-offs.
And then there are a lot of people who can
throw stones at all of this,
but if you're not in the middle of it,
and you don't understand, look, I understand some,
but I've been out of the sphere for enough time
to know I don't know, at a visceral level,
the details of everything.
And so, again, not just saying this because it's your podcast,
but the role you play, and being in a position
to actually understand, make a difference,
and having that conscious is just -- it's heartwarming.
>>I appreciate you saying that.
And I know that there are a bunch of other
very thoughtful folks pushing against the problem
as well at a bunch of companies.
So, I'm hopeful.
>>We're in your hands, so, please be. (laugh)
>>Yeah. We all need to look at this with the gravity
that it deserves.
>>Right.
>>It's just too important to be cavalier with.
>>Yeah.
>>So, you're at Zilog doing microprocessors,
software code design.
And then you become an entrepreneur.
>>Well, I was at Zilog doing the microprocessor stuff.
I was the project manager on something called
Z-Net, which was the first commercial
local area network.
So, while at Zilog, I had the opportunity
to be involved in the development
and introduction of this local area network.
>>And when is this?
>>I think in '79 or '80.
>>So, this is super early.
Like the state of the art for high-performance computing
then are like these big vector machines.
>>Yeah. So, we built a system --
part of the reason -- this was a semiconductor company,
a microprocessor company, why were we building
a local area network?
Zilog decided to go into the systems business
around their microprocessors.
And so what we did was develop
a local area network to interconnect these systems.
And our computing system was called an MCZ system,
which was an early PC, but it wasn't a PC.
And we had an operating system that was called RIO --
Real I/O, which was a predecessor
to the operating systems of PCs.
But Zilog was a microprocessor company,
not a systems company.
And so one of the things I learned was up until then,
I was an engineering elitist.
I thought marketing people weren't important. (laugh)
But I learned a really important lesson, which is:
If you don't look at the needs of the market
and match the technology, the technology is for naught.
And even if you meet those needs,
if you don't understand how to market and sell it
and you don't have distribution channels
that match up, you don't get anywhere,
you don't solve any problems.
>>Yeah.
>>So, it's fine if what you're doing is
research and discovery, and you're not trying
to bring a product to market,
but if you're trying to solve a problem,
you need all these pieces.
I very quickly, within those years at Zilog,
moved from being an individual contributor
to a first-level and then second-level.
I moved into management pretty quickly.
>>Did you enjoy the transition?
>>Yes. I --
>>And was it obvious to you that that was the right
way to go?
>>I never would have thought.
I, as a kid, was not one of these people
that thought I wanted lead,
thought I wanted to be an entrepreneur.
I didn't have a lemonade stand.
I didn't do any of that stuff.
And I found myself in this position,
and what I realized very quickly
is that I love people.
I love collaborating.
I love helping people and helping people develop
and leading a team.
And, you know, the fact of the matter is,
I wasn't a great software engineer.
I think what I was best at was the architecture
and the thinking about the kind of systems thinking.
I never wrote the fastest or best code.
And so, I ended up lucky that I had the opportunity.
By going to Zilog,
I also met the person who became my husband,
now my ex-husband.
We started Bridge Communications,
which was one of the early local area network providers.
And so the name Bridge
was about interconnecting networks.
And it was interesting,
our business plan, when we started,
was going to be about interconnecting networks.
And very quickly, we realized
there are not enough networks to interconnect.
And so we started off selling communications servers,
which were connecting devices into networks,
and then also interconnected those networks.
>>That's awesome.
So, presumably, you ran engineering and technology
at the startup.
>>Right.
>>So, you went from being a second-level manager
to the buck stops with you.
So, how was that transition?
>>It was -- So, Bill was the CEO.
I was the Executive Vice President
in charge of engineering
for the first couple of years.
But, you know, early on, it felt very natural.
And because Bill and I were partners,
we kind of shared a lot of the responsibility.
But the thing I really had to learn
was how to make decisions.
And not how to make decisions,
but how to make decisions in that kind of environment.
And as an engineer who loves solving problems,
I wanted to get it right.
>>Yeah.
>>And sometimes you have to make a decision
with the data you have,
and you can't know that it's right.
>>Yeah.
>>And it was a really interesting challenge for me.
Bill had a very different style than me.
He sometimes would say, "Go and fire that person," or
"Go pound on the table."
And there are people who are very effective
with an intimidating style.
That isn't me.
And if I had tried to be that, I wouldn't have been,
I don't think, as successful, because I wouldn't have been
authentic to who I am.
>>Yeah. I think that's really interesting.
One of the things that I struggled with
when I first became a manager,
I struggled with different flavors of this
for a very, very long time,
until I was managing hundreds of people.
I just didn't understand that in leadership,
many, many, many times, maybe more often than not,
there isn't a right and a wrong.
There's the best you can do at any particular point in time.
That's particularly true around people.
>>Right.
>>For a super long time, this is maybe the last big
management lesson that I learned is that I would
keep people on the team who were toxic for the culture
that I was trying to create just because by the numbers,
they were doing their job well.
>>Right.
>>And giving myself permission to say,
"Okay, this is my team, there's no right and wrong of it.
This is the group of people
that I want to surround myself with,
and this is the culture that we want to have
in order to go solve these problems."
That's sort of okay.
>>But you just used an interesting example,
which is there is no right or wrong decision, often,
but internally, you're guided by what is right or wrong.
>>Yes.
>>So, you used an example of not tolerating behavior
because of performance based on you're driven by what --
your values in terms of what is right or wrong.
I've seen leaders who use the excuse of,
"There is no right or wrong decision,"
to actually go in the opposite direction.
And so I think that learning how to be able
to make those decisions with a combination of
your gut and your intellect,
with a combination of data and compassion.
It's the balance.
It's why we're not machine learning algorithms.
Right? You know, we bring something different to it
because there's a lot of nuance.
>>I love what you just said.
This whole notion of data plus compassion,
I think actually does lead to the best decisions.
>>Right.
>>And that's a hard thing
to get pounded through the head
of a computer scientist.
>>Right.
I like to say that you can have data-driven management,
but you need human-driven leadership.
Leadership is not data driven.
Managing is data driven.
And so, you somehow have to combine the two of those.
>>So, at some point, like, your career --
you built this successful business.
You're this hugely successful tech executive,
and one of the things that you and I have chatted about
you were CTO of Cisco for a while.
There are very few people who have been CTOs
of big tech companies.
And I've gotten a bunch of good advice from you
about how to do my job.
So, what was the transition like for you,
going from entrepreneur,
you got the mission of the company,
you're building the team, you know everybody,
to, "Holy crap, I'm CTO of Cisco."
>>Yeah, fascinating. So, Cisco bought Precept,
and I became Cisco's Chief Technology Officer.
And that was in 1998.
So, I was there from '98 to 2000.
The company went from 18,000
to 36,000 people in that timeframe.
I was CTO.
I had legal, M&A also reporting to me.
It was fascinating to go from being an entrepreneur
who was always fighting, the scrappy company
fighting against big companies to all of a sudden
be at this company where everybody
returned your phone call.
Everybody wanted to see you.
And I loved learning a different level of issues.
It was also intensely frustrating for me,
because I was not building,
I was the CTO.
>>But you must have learned something in that role
about managing at a distance and via influence,
because you had these incredibly successful
and long board runs at Disney and at FedEx.
>>So, I was just about to say that I think it was the inverse
in some ways.
I had been on the board of FedEx --
I went on the board of FedEx in 1989.
So, I had been on the FedEx board for a long time,
which gave me exposure to the issues
of a big company, a different type of leadership.
I went on the board of Disney the same year
I became CTO at Cisco.
And I had been on the board
of Sun Microsystems for a while.
So, the board work gave me
a sense of scale and innovation
and the issues of that size company.
It also gave me a sense of how to make an impact
without direct-line responsibility.
>>And I think you had some really interesting moments
in your board tenure.
>>Yeah. That is true.
But I've got to tell you, the opportunity to serve
on the FedEx and Disney boards is just phenomenal
in terms of helping to build my understanding
of a bunch of different things of innovation at scale,
what it's like to use technology,
as opposed to being the developer of the technology.
The media business, what I learned at Disney
about the media business, and now that there's been
a confluence between the technology
and the media business,
it's really important part of my sets of experiences.
>>Awesome. Well, so, one last thing
before we let you go.
I want to talk about some of the stuff
that you've been doing more recently.
So, and you and I have been having conversations about where
both technology and technologists, potentially
can have impact, both positive and negative,
on the public good.
You're doing some really interesting thinking
and collaborations there.
So, tell us a little bit about that.
>>So, I'm spending a a certain amount of time
thinking and writing and collaborating in the area
of the impacts of today's technology on democracy,
on humanity, on media,
and trying to look at some of the unintended
and intended consequences of today's business model,
of the disruption of disinformation,
of addiction to technology.
There's a whole set of interrelated issues.
My concern comes from, often, we want to, again,
just look at a piece.
Is it data privacy?
Is it just election hacking?
It's a lot of things.
And so I've been working with a number of people both
in terms of writing and collaborating,
but also some specific things of, okay,
what are some of the things we can do about this?
And I really do believe this is similar to big oil
or big pharma or big food, where you have an industry
that is very successfully focused in an area,
but there are consequences.
And then what happens is there's opportunity
in developing alternative energy.
There's opportunity in developing healthy food.
And the existing legacy companies have a choice.
They can either choose to understand
the consequences of their action,
and embrace that opportunity and work with new companies
and, ultimately, open up to provide
all the wonderful things they provide
without some of the harm. Or they can deny climate
and go in their hole
and, ultimately, they'll get regulated, disrupted --
hopefully, in the climate case.
But I just think we need to be more aware of
all of those consequences.
So, I'm spending a certain amount of time on that.
>>Which is fantastic.
And I'm really, really glad that you are engaged here,
because one of the real difficulties that I see
is that these issues are, I think, unprecedented
in terms of the complexity.
There's just nothing in human experience
that would let you develop an intuitive feel
for what's happening under the hood
of some of this technology.
And it's not all sinister, right?
I would put forth that most of this stuff,
like the vast majority,
especially built by tech companies,
is like well-intentioned technology,
where we haven't thought about the
second-order consequences of
what people are going to do with them,
and a variety of different things.
But getting the public to be informed enough
about how these systems work so that they can have
a degree of agency, they understand what's going on
both for themselves, and for how they are
pushing their own advocacy out in the world
for how they would like things regulated,
and how they would like companies
to better serve them.
I think is really, really important.
And it's tough because of the complexity.
>>Yeah, it is tough.
And I think that we just need to keep in mind --
and you said it, it's not that people are bad,
but we look at the incentives of organizations.
When we were talking about making decisions,
all of these decisions are made by who are you serving?
And so it is easy in a capitalist, for-profit
environment that you serve shareholders
who are pushing you for short-term returns,
to want to maximize growth.
It's not like your trying to do harm,
but you're measuring the things.
We manage what we measure.
And if we pick those metrics around things that are
focused on short-term growth, short-term profits,
it's not like we want to do harm,
but we're not measuring the harm.
And if you're not measuring the harm,
then the people in the organization
don't rally against it.
And I am fortunate at this point in my life
to have the understanding of technology
at a broad level,
but no longer being in the middle of an organization
or set of organizations.
So, I see if I can bridge that gap without an agenda,
so having an understanding of the for-profit world,
having an understanding of those incentives,
understanding technology,
but now being independent enough
to actually be able to look at it and say,
"You know what? When I was doing that,
I had that problem also, but now I can see
that we need to think about how to change that,
because it's doing harm."
And so I'm just really fortunate
to be at a point where I can at least
try to add my voice to the debate.
>>We're so glad that this is
how you're choosing to spend your time.
So, thank you so much for being on the podcast today.
>>It was my pleasure.
Thank you for inviting me.
(music)
>>Well, thanks for joining us for
Behind the Tech.
What a great conversation we just had
with Judy Estrin.
>>Yeah, it was really great hearing the two of you talk.
And hearing about Judy's career
and all the things that she's done
and how she's literally been involved with the Internet
from basically, its inception through the present
is so interesting.
>>Yeah. Now, Judy has been an incredible mentor to me.
Her story is inspiring.
She has so much wisdom.
She's such a good technologist.
I've learned a ton from her over the years.
>>I was really struck by one of the things that she said
in your conversation where she was talking about
growth without the expense of humanity.
And how that seems easy to say,
but seems in practice, actually, really difficult.
>>I think there are a bunch of things that we can do.
She was sort of dead on with this notion of we don't
don't fix what we don't measure.
And part of what I think we're learning right now
with some of the things that are going on
in the tech industry is how to measure some of
the things where people are using
the technology that we've built in these sort of unanticipated,
bad ways.
And I think we will learn very quickly as an industry,
how to get better on this stuff.
But, I think it really is going to
require us to start thinking about our role
as computer scientists and engineers
and technologists a little bit differently.
And for us to start when we are educating folks
to make sure that that human part of the job
is just as well emphasized as the technological part.
I went to a liberal arts school to get
my computer science degree.
And even there, at a liberal arts school,
things like taking an ethics class weren't mandatory.
I wound up taking a philosophy class.
We've sort of developed over the many centuries
this whole notion of a liberal arts education
because it's important. What all of us
have to like really understand, especially
those of us who are in fields where we're
building technology that has
such a pervasive impact.
>>Do you think having that background in humanities,
do you think that helped you as you became a technologist,
and as you've transitioned into becoming a manager
and now an executive?
>>Yeah, I think it has in interesting
unanticipated ways.
If you'd asked me the question 20 years ago,
probably I would have said, "Not so much."
The obvious things I think that it helped with
were with just writing,
for instance.
And being an effective communicator.
The thing that I think is really useful,
part of this is --
part of this, I think you sort of learn more
from being a manager than you do
from a liberal arts education,
is just having compassion for people.
Once put yourself
in the mindset that,
you have to take care of people,
it really does change how you make decisions.
And, I think if anything,
what we need to have a consistent understanding of
in the technology industry is, like, that's our job.
We have to take care of the people
who are using our products.
>>So, Judy talked about her transition
from being an engineer and into management
and entrepreneurship.
Did you relate to any of that at all?
Did any of that kind of resonate with you
in your transition from being an individual contributor
to leading hundreds and thousands
and more people?
>>Yeah, no, totally.
I think it's really interesting to see
what a consistent experience that is for leaders.
I think a lot of what Judy went through,
I went through as well.
It's really challenging as an engineer
to go from this mindset of, like,
"Okay, I'm solving problems
that have a right and a wrong."
To, like, "Okay, now I'm solving problems
that don't have a right and wrong."
And a bunch of constituencies
who are asserting their right to be heard,
and you have a bunch stakeholders involved
in the outcome of the decision,
you gotta just sort of basically,
make calls on imperfect and incomplete data.
And I think that struggle is something that every
leader goes through at some point.
It is an interesting transition.
And it makes you, on many days,
wish that you just stayed an engineer.
(laughter)
>>That's really -- that's amazing.
But I think what you're just talking about,
again, goes back to kind of what I picked up
as the thesis of you and Judy's discussion,
which is all about thinking about
and being aware of consequences
as you're building things.
>>Yeah. And given the complexity of the things
that you're building that is easier said than done,
but increasingly necessary, nonetheless.
>>Well, I'm glad that people like Judy
are working to help other businesses
and other people think about those things.
I'm glad that you're aware of those things
and are doing that as well,
because we definitely need
all the help we can get.
>>Yeah. I'm super grateful for the folks like Judy,
who are choosing to use their time in this way
to like try to benefit everyone.
Great conversation, Christina.
Looking forward to chatting with you again
on the next episode.
>>I can't wait.
Next time on Behind the Tech, we'll talk with Danielle Feinberg.
Danielle is director of photography at Pixar Studios.
Her love of combining computers and art began
when she was eight years old.
This eventually led her to a BA in computer science from Harvard.
Today, besides making films for Pixar, she mentors teenage girls,
encouraging them to pursue code, math, and science.
So, be sure to tell your friends about our podcast,
Behind the Tech, hope to see you next time.
For more infomation >> Creative - V.I.P (Audio Oficial) - Duration: 3:45. 
For more infomation >> Corsa: 10 curiosidades de um Chevrolet que mudou os carros pequenos | Carros do Passado | Best Cars - Duration: 4:35. 
For more infomation >> New Omaha ordinance limits July 4 fireworks use to 3 days in 2019 - Duration: 2:09. 
For more infomation >> New merger allows credit union to help underserved communities - Duration: 1:34. 
For more infomation >> Mejor Me Alejo Banda MS Tutorial - Duration: 6:56. 
For more infomation >> Man accused of reckless conduct for shooting dog that attacked pet - Duration: 1:59. 
For more infomation >> Maine RB Fitzpatrick making impact in Orono - Duration: 0:52. 
For more infomation >> Is weed killer causing algae to form - Duration: 1:24. 
Không có nhận xét nào:
Đăng nhận xét