Looking back on a career building tech partnerships
When Cathy Gordon joined Google in 2003 she was the oldest employee at the company. She had already worked in technology for over 25 years. Cathy is an elder stateswoman of tech partnerships. She helped define the function we know today as Product Partnerships.
Many of today’s tech giants scaled by digitizing the physical world. Amazon digitized the store. Salesforce digitized the rolodex. DocuSign digitized contracts. Doordash is digitizing menus.
But Cathy’s tech career began before all that - in the mid 1970s - helping Lexis to digitize legal case law and statutes into a form searchable by computers. Back then lawyers still relied on law books that were housed in legal libraries.
Cathy was building tech partnerships when the digital tidal wave was just a tiny ripple.
My hope is that this conversation with Cathy looking back on her career gives you some perspective on your own career journey.
Career advice
When you look back on your career and the setbacks and frustrations you experienced, what advice do you have for those facing their own challenges?
One of the things that has always helped me and what I recommend to people who I talk with about careers is that knowing yourself can be put into a map. And the map is: (1) what are you good at? (2) what do you love to do, (3) what are you not good at, (4) what do you hate to do?
For example, I was talking to a woman in sales at Google and she said “I am really good at cold calling … but I hate it.” Well, she could start to fill in her map with these data points. If you can build that map it can last for a very long time. And you should add to it as you get more knowledge.
What are you not good at? That's your learning quadrant. When I would do performance reviews, I would ask “what is in your learning quadrant?” Where do you want to go? What are the things you want to know more about? How can we move you in that direction?
If you know your strengths and weaknesses, the things that you love and the things you want to learn, as well as what company and managerial structure work best for you can be used as guideposts..
If you're stagnant in a job, for example, can you define something new that you can learn that could take you in a new direction?
And find a mentor if you can or someone who you think can provide you with constructive criticism. Ask you the right questions. Because you don't always know the questions to ask.
Over the course of your career I imagine you saw talented people whose careers soared and others who stumbled. What factors most commonly set apart those who you saw succeed?
One of the most amazing people I worked with was Megan Smith. Megan was always out and about. She went and learned something about everything. She had these notebooks. She would just scribble them with all the stuff she was learning. And she was connected to all these different people and these different ideas. She was good at thinking “oh this thing over here would be really good to connect to this thing over there.” People who are willing to go learn and connect - that's a really, really important skill.
If you're away from your desk, you're meeting people and you’re connecting with people. You're exchanging ideas and you’re hearing what it is that they think they can accomplish. And you see how that connects with your skills and projects.
I would say most of my team were of the sort who was always out and about. When we would have staff meetings, we would go around and each team member reported “this is going on here” and somebody else would say “oh, what about this?” And somebody else would say “oh I could get you some resources over there.” This sharing of ideas was enormously important because everyone had their ear to the ground. And they knew so many people. And by doing that, you get an opportunity to join in and to prove yourself.
Business Development always faced a question of “what do you do? So you had to prove what you could do. We had to prove to [Product and Engineering] how we could help them do their job, essentially how to get to a yes/no decision.
When I was doing career counseling, the ones who had a sense of where they wanted to go or the kinds of things that they wanted to work on were the ones who were going to be successful.
Partnerships & Google’s early days
You were at Google during a really interesting period. What are some of your memories from that era?
Google was just two buildings back then. That’s all it was. And the food for the entire company was cooked on a couple of stoves in a tractor trailer.
I remember saying to Susan Wojcicki or someone else “do you know what this is going to cost?” And the answer was, “we don't care, this is something we need to do.” There was a belief that there were things that they needed to do to fundamentally shift things. That feeling was so strong that the logistics and the obstacles were just literally considered no big deal.
One project I worked on that was fascinating was digitizing all of the US patents. At that time the US Patent Office had digital records from 1976 onward. But before that, everything was in print. And the only way you could access patents from before 1976 was either through an extremely convoluted US Patent website or you could pay through the nose from companies that would license them to you for a large fee.
We got copies of these patents in print and using technology from Book Search we scanned them. Google ended up with the only freely available digital database of all the US patents. It took about two years. Here we were just disrupting an entire market.
How did you distinguish between “partnerships” and “business development?”
Most of the work that I did at Google and at other companies was what I would call ‘new business development.’ We called the stages of development dirt road, gravel road and paved road. My team mostly worked on dirt road projects, that is, really early stage projects in which partnerships may or may not be a piece of the work being done. We would look for the best way to assist product/engineering to get to a decision on an idea’s feasibility.
If you look at most job openings for business development they are mostly sales - go out and get customers. Whereas we [at Google] always had a focus on helping product/engineering develop something.
What we would do on early stage projects were usually three options: “Are you going to build something? Are you going to buy something? Or are you going to partner?
At Google, in particular, the inclination was to build it, regardless of whether there was anything else out there. And so our role was to provide [Product] with options for partnering or licensing.
Did you have certain BD commandments or “Cathy-isms” that you lived by with your partnership teams?
I don't know whether they're Cathy-isms or just common sense.
It was really important for our New Business Development team to embed and work alongside Product and Engineering. Sitting in an office across campus was not going to enable my team to get up to speed on what the Product team was thinking.
Part of the reason for that was our New Business Development team had to define the “must do’s” versus the “nice-to-have’s” for the product. The definition of “must do’s” is that this product will fail if you do not do this.
Our focus [in New Business Development] was to help Product and Engineering get to a “yes / no decision” which was typically “yes, we have proven this out so we can continue working on it” or “no, whatever we are trying will not work.”
The skill set of my team demanded that you had to be able to come up to speed really, really quickly on something that you may not know anything about in order to help [Product].
Another thing that was really important was build / buy / partner, which means that you really had to understand the fundamental goal of the product. Many times, it was a wonderful idea but [Product] didn't actually have a fundamental goal for what was being built. It was just “let's see if we can fiddle around with this thing and see if it can work.” We would work with them to articulate the idea’s value and fit.
Lessons from partnership success and failures
Is there a partnership or a deal you worked on that demonstrated what a win-win partnership looks like and can achieve?
I think that the early Book Search deals were a win-win for both book publishers and Google.
[Google] had no product when we started licensing books. One important thing about partnerships is that it can be easy to get ahead of where the product development is. That is not a good thing.
When we got started with Book Search, Amazon was the 800 pound gorilla. They had just introduced “Search Inside the Book” thus taking more control of the sales process. The publishers were really concerned about this power shift.
Because the publishers had the authority to do marketing deals with their book catalogs, we [Google] signed contracts with them to digitize, make them searchable and put them online. The wins for the publishers were significant.
First of all, big publishers like Random House - they may have 30,000 books in print - but maybe 100 of them are on bookstore shelves. And so those that were not on the shelves were invisible to the buyer. So they wanted to expose their back catalog.
Secondly, book publishers were now starting to build their own websites. Google provided a “buy this book” function and the publisher’s website would always be the first buy link [in Google Search]. Always.
Google’s win was getting access to a huge corpus of free print materials and being allowed to make the books available for search, as well as the technical knowledge we gained from digitizing and OCR. Publishers received incremental sales of their books.
What lessons did you take away from the products you worked on that struggled?
For the really early ones, for example with Google Health, we did not understand the needs of the partners as well as we should have nor did we educate them on what to expect from a product under development..
We were working really hard to get pharmacies to provide an individual’s prescription data into a personal electronic medical record. So we signed up some of the big pharmacy chains like Walgreens and CVS. They thought they were going to get millions of customers. Our expectations were that there would be an easy way for customers to connect and download their records. Neither of these expectations were met–they didn’t get millions of new users and the pharmacy process was too difficult for users to get their personal data.
Another time I did a partnership deal to acquire a full-text business feed for 150 business journals. I thought “This is wonderful! They’re going to give the data to us for free and we can make all this valuable information available in search with no paywalls." I went trotting down to Engineering. And they greeted me with a blank stare. They said “what’s a data feed? We crawl the web.”
Eventually Google built tons of data feeds. But this was 2003. So the lesson for me was about not getting out past the capabilities and priorities of your Product and Engineering team.
You've got to really understand the goals of both sides. You also have to be fully transparent about the state that the product is in, which we weren't.
On ageism vs. sexism
What was it like to be the oldest person at Google when you joined? Did you feel a stigma about being different.
I never felt any ageism. Part of the reason was that I had been in tech for 27 years since 1976. I had watched tech grow from a crazy idea into something valuable and powerful. And Google was this incredibly logical next step in the career I had already gone through. To some extent, because of my experience, I was way ahead of a lot of people. I could ask the questions that needed to be asked. I could make decisions because I had already done them. Google employee’s average age was mid-20s, intellectually brilliant, but with little real experience.
Do you feel that the dynamics for women in tech are improving?
I think sexism still exists, I can’t tell you now to what degree it is. In my experience there was definitely a glass ceiling. When I was at Dialog, this was probably 1995, there was finally an opening for a VP of Product. And I interviewed for it and was qualified for it. And then they promptly went silent. And I knew they were interviewing lots and lots of guys. At that time, there were a lot of startups out there, so I found a startup and got a good job offer. Then, I laid my resignation papers on the HR guy’s desk at Dialog and I said I’m leaving. And he said “no, you can’t do that. We want to hire you for the VP role.” . But I now had leverage. I was the first female at Dialog on the senior management team.
If you look at Google when I retired, there were some females at the VP level, but women struggled to get to the small cadre of key senior executives - except for Susan and Ruth Porat. I don’t know if this has changed since I left. It’s frustrating because women need mentors. They need female mentors. But I think they also need male mentors, because men think and act differently.
There is a feeling that if a man is pushing something, that’s okay. But if a woman is pushing something, that’s not their role. My hope is with the younger generations that girls are learning to be more assertive and that the guys are more accepting of that. A much bigger issue, getting more women and minorities in tech is not yet solved and is a really tough issue to solve.
