Month: September 2020

Cathy Polinsky, former CTO at Stitch Fix, chatted this week with Pear associate Harris, who leads our talent initiatives. This is a recap! Watch the full talk at pear.vc/speakers.

It starts as an obsession. You play with your first coding language, and you’re hooked. You keep learning new languages and building cool things with your new skills. You’re doing this in an exciting environment with enthusiastic mentors who support you.

Cathy Polinsky, former CTO at Stitch Fix, was lucky enough to grow up this way. In the 80’s, Cathy’s mother was a teacher, and Apple personal computers had arrived at school. Cathy’s mother thought the technology was interesting and bought one for their home (before they had a VCR!).

Cathay learned her first programming language, Logo, and went on to learn basic programming. Computer science was so new then that there wasn’t formal education for it in school, but growing up in Pittsburgh meant that Cathy was able to go to a summer camp at Carnegie Mellon.

“We did algorithms in the morning and more hands-on programming in the afternoon with robotics and maze solving problems, and I just really got hooked and knew I wanted to study it after high school,” said Cathy.

Sure enough, Cathy did just that, and went on to a thriving computer engineering career. In this fireside chat with Pear, she looks back at her career and highlights the building blocks she gained from each role to help future engineers make decisions about their own careers.

“A career is made in hindsight, not while you’re on that path. While you’re on it, it might not feel straight, but you can in retrospect see this arc of where you’ve come from. I’d say I have a little bit more of a clear arc than most, but I know many other people who have had different paths that have gotten there or to some other destination that they have been really excited about.”

Laying the groundwork as a software engineer scaling early Amazon
Hands-on, non-stop building at an early stage startup
Moving into management and people skills at Yahoo and beyond
Cathy’s Career Advice
Cathy’s Advice On Hiring
Tactical Hiring Tips

Laying the groundwork as a software engineer scaling early Amazon

Like many young graduates in computer science today, Cathy’s first job out of school was as a software engineer at a fast-growing company — Amazon, in 1999, right before the dotcom crash.

“I thought I’d missed the interesting times at Amazon. I thought I’d missed the early stage startup. Little did I know, I was living the interesting times. It was a gritty time. I was there during the dotcom collapse and all my stock was underwater,” Cathy recalls.

Things were still early enough for Cathy to grow fast with the company (she had a door desk when she started!). Amazon was in the hundreds of engineers then, and everyone was brilliant, but the rapid pace meant that the environment was a bit chaotic. The code base was a mess for example, with little documentation.

“It was an amazing time where I learned how to be an engineer being in a company that was scaling so fast. I learned a lot about how to hire people earlier than any other job I would have gotten,” says Cathy.

At Amazon, Cathay had the opportunity to learn from the tech giants. She developed solid, rigorous ground for her career learning to ship things at scale and having to think through everything from interview process to database and schema design, to hardware constraints and automation and testing.

But in addition to engineering skills, Amazon helped Cathy to gain a deep appreciation for the growth mindset — a mindset that serves her even today.

“Jeff [Bezos] never wanted to be written in an article and have Amazon in the same sentence with any other early stage dotcom company. He only wanted to see himself with the giant companies that were out there. I’d say that I was much more of a voice of growth and opportunity as a leader at Stitch Fix in the sense of: ‘How can we invest more, and how can we grow more?’ and making sure that we were keeping our eyes always on the long-term.”

Hands-on, non-stop building at an early stage startup

Cathy soon got the startup itch and wanted to see what early startups were like, so she went and joined a 13-person startup in San Mateo.

At first, with only two years of work experience at a scaling company, the early startup environment felt quite different. Cathy was surprised to learn that there were no automation suites and other big tools she took for granted at Amazon.

“But, I wrote way more code there than any other place, and I got to wear more hats and I got to go to a pilot customer and be involved when we were doing discussions about name changes and logos,” says Cathy. “You got to interact with people that weren’t just tech and be much more involved in the company on a different scale .”

Cathy also experienced the pain of building great products that didn’t work out.

“The company never really got off the ground. We only had two pilot customers, couldn’t get sales. There was a recession going on. It was heartbreaking when we closed the door to feel like I put so much of my blood, sweat, and tears into building something that I was really proud of.”

It was valuable first-hand experience in understanding that a successful company was not just about building a great product, but also about building the right thing and checking in with the market for early feedback.

Moving into management and people skills at Yahoo and beyond

After the startup heartbreak, Cathy turned back to big company world, though she “wouldn’t recommend to anyone to overcompensate that strongly,” she laughs.

At Oracle, Cathy realized she missed the fast pace of earlier companies, and sought to move into management. A friend pointed her to a position opening up at Yahoo.

Cathy ended up being offered her choice between two roles there — an engineering management role and an engineering lead role. She decided to try management and never looked back, going on to lead engineering at Salesforce after Yahoo, and on to the C-suite at Stitch Fix.

One of the first lessons Cathy learned in her first management role at Yahoo was to stay out of the code. The engineering manager she inherited the role from said that she regretted being so hands-on and jumping in too quickly to fix bugs or help her team with the solution.

“I really took that to heart. If I’m jumping in to heroically save the day, I’m not actually working on the fundamental issues that are going to help the team be successful in the long run. That has really influenced how I spend my time and how I look at the role,” says Cathy.

That is, transitioning into a management role means focusing your attention more on the people issues rather than the tech issues.

“I’d say that I choke often — that I would have been better off being a psychology major than a computer science major,” Cathay laughs. “Dealing with people in some of these large organizations is much more complex, and not deterministic in any way. You never know if you’re doing it the right way or not. I think that I’ve spent more sleepless nights thinking about people issues than I have about technology issues.”

In all the companies Cathy has been in, it’s been key to treat every single tech production incident as a learning opportunity.

That’s because if you’re shipping software, it’s inevitable that you are going to break something eventually. So, the question software engineers should be thinking about isn’t “How do we avoid breaking things?” but rather, “How do you make sure you don’t have the same problem happen again, and how do you make sure that you learn from it and get better and have other people around you learn from it, so they don’t have the same mistake that you had?”

Cathay is a fan of blameless postmortems.

“We get in a room and we do a postmortem of what happened, but the only rule is you can’t point fingers at anyone. You don’t name any names. You’re not trying to get anyone in trouble. If you can really approach any problem with that open mindset and learning, then you will make sure that you uncover all the problems in the areas and you won’t have the same problems again.”

Cathy’s Career Advice

• There’s no wrong answer to big tech vs. join a startup vs. start my own company.
• Take the roles where you’re going to learn the most.
• Follow your passions.
• If you are interested in something that’s different than what you’re doing today, just tell people that. People will see you differently and think of you when opportunities arise when you tell people what you’re passionate about.
• Don’t worry about where you’re going to be 10 years from now, but have an idea of what you want to do next.
• If you don’t know what you want to do next, talk to a lot of people.

Cathy’s Advice On Hiring

Anytime you can, hire someone smarter than you.

A lot of people have a hard time doing that. They think, “Oh, they have more experience, or they’re smarter than I am, what am I needed for?” You will never ever fail if you were hiring people that are smarter than you and know more than you.

Extend outside your network and find people who are going to push you.

I have worked in a lot of companies that focus on hiring within your network and telling the great track record they have for internal referrals. As a woman engineer, I think that’s really dangerous. I think that you have only a specific network of people and if you continue to hire people in your network, you’re only going to see people who look exactly like you and you’re not going to push yourself and get diverse opinions around the table. You’d be better off really trying to extend outside your network and finding people who are going to push you and bring different experiences to the table than you have in your own. That’s something that we were really intentional about at Stitch Fix — making sure that we were reaching out into diverse networks and seeing people that were different than the people that we already had.

Follow the structure of what you set out to do — don’t rush.

One of the challenging hires was not someone who worked directly for me, but was one level down, and was a referral from someone in the organization. We did a rush job hiring and leaned on the referral, but really did not show up living the values that we had as a company. We started to see some things that didn’t show up the way that we would expect for someone of their level. When we did a debrief on what happened, we realized that we hadn’t done reference checks and we hadn’t really done a full check on: ‘Is this person a good fit to the values that we had?’ It was a pretty big miss that we hadn’t followed the structure of what we had set out to do and really caused a lot of friction across the team because of it.

It’s critical to understand what you need for the stage of your company.

In the early days, Amazon would rather hire someone that had a couple of amazing interviews and a couple of bad interviews than someone who was mediocre across the board. They wanted to see someone who really excelled in a specific area, even if it meant they had holes in other areas. I like that sense of playing to someone’s strengths, especially as a larger company, you can take more liberties in that way.

It’s harder in an early stage company… you have funding for three hires. You’re going to need to hire some real generalists who like to build things, who can also answer phones and do hiring and operations and the like. Thinking about those first hires as generalists who are interested in getting to wear a lot of different hats is important. It’s kind of fun for the people who do it, to get to build things from the early stage.

Then you have to think about how you scale it. Because at some point, those people are probably not going to be happy after you get to a team of 100 where they’re not the best at any of those things. Either they scale, and they still know everything and are this amazing person that can jump in anywhere and add value, or they get really dissatisfied that they can’t really play the same role that they had before.

As you’re scaling things out, you’re hiring more narrow generalists of, “Hey, we really need someone who understands AWS deployments, or we need someone who really understands this mobile technology stack,” or whatever it might be.

So, if you’re really thinking about building and scaling with the business, as the business scales, you have to think about what stage you’re in and know that what works before is not going to be the thing that’s going to be successful after you get to 50 or you get to 100.

Tactical Hiring Tips

• Take home interview questions and pair-programming interview questions are a good way to see what people are going to do in their day to day. You don’t work by yourself — you work in a team and so seeing how people work with a team is good.
• Have candidates interview with non-technical team members and solve a problem together. It’s important for technical people to be able to talk with nontechnical folks. At Stitch Fix, this practice has enabled a much higher EQ team.
• Have inclusive language in your job description and list fewer requirements to be more welcoming to women. Avoiding bro-like or gendered language is of course the obvious thing to do, but what might be less obvious is that long requirements can rule out certain populations of people! Men will tend to apply anyway despite not meeting all requirements, and women will tend to filter themselves out because they don’t have nearly enough of the requirements on this list.
• Sit in on every debrief. You don’t necessarily need to meet every candidate, but you should listen carefully to candidate discussions and guide your team. “There were times where someone would explain the interview and then have a strong assessment on whether we should hire the person or not. I would listen to their rationale, but not agree with the outcome based on their assessment, so we could talk about that and dig in. Sometimes there were some things that changed the way that they thought about the interview, for example, something like, “They weren’t very confident in their skills.” We would ask, “Why did you think that?” And it could just be a passive word choice that they used, and someone else points out, “They’re actually really confident over here — and is that really a job requirement that you need?”

As we move into the last days of summer, with the world still very much uncertain, we highly recommend giving Bob Baxley’s Pear talk on conditions, constraints, and convictions a watch at pear.vc/speakers.

Bob shares three Cold War stories of magnificent innovation — reminders of the amazing things humans have accomplished and can still accomplish even in trying times.

Below, find insights from the Q&A session for thinking about conditions, constraints, and convictions for our own times.

When are constraints good for creativity, and when are they bad?
What can founders do to help creative teammates be most creative?
How do you figure out which problems to solve and which to defer?
What signals can you look for to indicate that you need to engage the creative side more, versus getting it done?
How do you find inspiration for design during the initial brainstorming phases?
How can we think about current pandemic conditions of not being able to see each other?

Q: Constraints may have boosted Dr. Seuss’s creativity, but it seems that a lot of conventional wisdom also suggests that having too many constraints can be bad for creativity — how do you reconcile this?

I think the question is getting at two different kinds of constraints. One is a resourcing constraint and the other one is defining the problem space. Trying to do too much with too few people is a different challenge. That’s really a question of prioritization, so I’ll leave that aside.

As a creative professional and somebody who’s been designing software products and leading teams for three decades, the worst thing you can do is to give me a lot of space and a lot of time. Every creative I know, we’re master procrastinators. We will always put off finishing the thing. If we have a big, giant open field, we don’t quite know how to get started. I’m a big believer in a well-defined problem space.

I like making sure that you have to show progress on a steady basis. With my teams at Apple and now ThoughtSpot, the team has to show me work basically every 48 hours. We are constantly looking at work. It keeps people from getting too caught up in their own heads and wandering off in the wrong direction, and it keeps us together as a team. It reduces a lot the emotional, creative pressure on people.

Structure’s the difference between an empty field and a baseball diamond. You can’t have a game if you don’t have the diamond. You can’t make progress if you don’t have the diamond. You’ve got to have some boundaries to make progress and a ton of amazing art.

If you really go back and you look at Chopin’s Preludes are Bach’s Goldberg Variations, there’s a ton of different, great artistic achievements that were set up as a technical problem that the artist was trying to solve. They go into the work that way. Most artists don’t just show up at the canvas and see where it goes — like they’re trying to accomplish something.

Q: What can we, the founders, do to help our creative teammates be most creative and set the right constraints without setting too many?

In all designed problems, what you’re trying to do is help the person to understand the problem. Don’t get prescriptive about the solutions. Try to make sure we’re trying to accomplish the same goal, and then evaluate the design solution in the context of the goal.

A story I tell is: at a company I was working at years ago, we had a homepage. There was a link on the page, and the product manager said “Bob, you have to make that link blue.”

I said, “Why do we have to make a blue?” They said, “Just make it blue.”

We got in this debate about it being blue. I said, “No, I don’t want it. That’s going to ruin the aesthetic of the page.” And they said, “Well, I want it” and went behind my back and made it blue.

Then we had a heated discussion in the hallway. I eventually said, “What was it you were trying to accomplish by making it blue?”

Turns out, people couldn’t see it. And I said, “Oh, so it wasn’t prominent enough?” And the product manager said, “Yeah. It wasn’t prominent enough.”

I said, “Okay, great. Well, we’re professional graphic designers. We have 15 ways to make it more prominent, one of which is making it blue. What you did is you leapt to a solution, and you didn’t really present the problem to us.”

For founders and executives, I spend most of the conversation trying to get them to more specifically narrow down our understanding of the problem and to make sure that we’re on the same page with the problem. The benefit of doing that is that when you find the right solution, everybody will agree.

I often get questions about how to resolve creative conflicts between different design solutions. I always say — that means you haven’t agreed on the problem. Because if you had a shared understanding of the problem, the solution would be obvious.

Q: How do you and your team tend to figure out which problems to solve and which ones to defer or ignore?

Here’s another story, about my friend Steve.

When Steve was getting ready to work on Keynote for the first time, Steve went to Roger Rosner, who was the VP of engineering responsible for iWork. Roger asked, “How should we think about Keynote? We got to compete with PowerPoint. There’s already these other presentation packages. What should we do?”

Steve said, “Roger, there’s three things with Keynote. One is it should be really difficult to make ugly presentations. Two, you should focus on beautiful cinematic transitions. And three, you should optimize for innovation over PowerPoint compatibility.”

I use those as examples of strong tenets. Each one of those statements, for example, if we just take the last one, optimize for innovation over PowerPoint compatibility — you could imagine the thousands of hours of debate that the product team would have had if they didn’t have clarity on which side of that debate to be on.

Steve just said, straight off the bat, make it difficult to make ugly presentations. That’s a whole set of things to take out of the way. So, we get beautiful cinematic transitions, which to this day is the hallmark of Keynote and why I can’t stand using Google Slides or PowerPoint. That’s a very clear direction.

I think a lot of times when you’re trying to figure out what to do, do you really have clarity around the tenets? Because if you have that clarity, the priorities fall out much quicker.

Q: What signals do you look for in your own work that indicate you need to engage on the creative side more deeply versus buckling down and getting it done?

This is an interesting question we’ve been dealing with internally at ThoughtSpot. When does something pivot from being exploratory creative work to execution mode? It’s always a delicate balance, and it’s a little bit like being a parent. When do you give your kid that extra thing to go do? When do you let them go further, versus when do you stay closer to them?

There is a point with almost every project where the team has some sense of, “No, this is really what we want to go do.” I can’t give you a rubric for how to judge that, but you can usually feel it in the room. The debates are becoming more and more myopic and you don’t seem to be making the same level of progress. There seems to be general agreement that this is the thing we want to go do. At that point, you have to pivot into execution mode. There’s a point where you just have to sit down and finish the thing.

As a creative, I enjoy working in both those modes, because it’s emotionally draining to sit in that level of uncertainty of wondering what we’re doing. There’s a point when it’s actually really rewarding to put all that uncertainty behind you and just go and finish the dang thing.

We tend to do that with deadlines. We sign up for some sort of commitment. Maybe there’s a company event that you have to have a demo ready to show. Maybe you have to give a presentation like this. You sign up for different kinds of commitments, and then you can use that commitment as a forcing function.

Q: How do you find inspiration for design during your initial brainstorming phases?

In terms of software, I spend a lot of time just looking around in the world. I’m the annoying guy at the deli that asks to look at the point of sales system. How does the Clover UI actually work? I sit and chat with people about self-checkout at Safeway and how it sucks and why it sucks. There are software products everywhere, so there’s tons of inspiration to be found just looking around the normal world.

Q: We have a lot of new constraints these days — one of which is that we’re not with each other. What are your thoughts on our current conditions, and where do you see it going?

I’m on the side that says there’s no great reason to go back to the office. I always try to get my team to separate the idea of working from anywhere from the idea of the lockdown. Imagine your kids are still going to school, and imagine you can go work at the Starbucks, and you can go see your friends for lunch. You can work from Hawaii if you want. How does that feel?

Most people say, “Oh my God, that feels awesome” — so, it’s not the working from home thing, it’s the lockdown. The lockdown is not something within our control, as individual companies or individual citizens. So you have to parse those two.

I firmly believe that we can make this work, and I think there are some unique benefits to working from anywhere. The fact that we can do things like this company events with a few hundred people from around the globe — we wouldn’t have done that in the past. If we had, it would have been a huge deal, and it would cost us an enormous amount of money.

You’ve got to dance with the constraints, and stop thinking about what you’ve lost by not being in the office, and start thinking about what you’ve gained — because you’ve gained a lot.