Creating Community

Elizabeth: Hi. I'm Elizabeth Ferrao. I am the co-founder of Women Who Code New York City.

Suzanne: And you are also entrepreneur-in-residence at Civic Hall. Is that because of Women Who Code? Is that the entrepreneurial pursuit that has you here?

Elizabeth: Yes, it is. So Women Who Code is a global nonprofit. I co-founded the New York City network, and Civic Hall is a wonderful place where companies who are working on for-good applications can come and collaborate with each other.

Suzanne: Tell us a little bit about Women Who Code. How did it get started? How did you come to be involved with it here?

Elizabeth: Yeah. I had attended a number of events in Women Who Code San Francisco five years ago, and they were fantastic. I loved the San Francisco events. There were so many female software engineers there, and that was unheard of for me as a college student. When I had moved to New York City, I was wondering why there wasn't that same community of Women Who Code, and that was when I decided to start it.

Suzanne: So did you study computer science in school, like that was the path that you were already kind of charting for yourself?

Elizabeth: Yes. I studied computer science for a year and a half, and then decided I didn't like the theory as much and decided to drop out afterwards.

Suzanne: But you are a developer, so maybe this is an interesting opportunity to understand, because the education landscape is really changing around, you know, there's programs like General Assembly, there's no shortage of online trainings, there's organizations like yours. Do you need a computer science degree now, and what is that really about as opposed to just learning how to do it?

Elizabeth: Yeah. I think the technology industry in general is a lot more skills based versus resume based, and I have found that as a developer, it matters most about your skills. It matters whether you can get a project done, as opposed to which school you've gone to and have a piece of paper up on the wall from.

Suzanne: Right. So just get into it. Roll up your sleeves.

Elizabeth: Rolling up your sleeves, complete a project, and be consistent with it.

Suzanne: So was Women Who Code in San Francisco then kind of the beginning of your practical education?

Elizabeth: A little bit, yeah. The combination of those fantastic meetups where I was actually starting to build things. That and actually General Assembly's Front-End Web Development course was what got me on the path to actually building.

Suzanne: Right. What are the requirements here in New York City for Women Who Code? Is it just, "Hey, if you identify as a woman and you're interested in development, you should come out"? Or, there's kind of a you have to know these sort of basic things in order to get value from the events and experiences?

Elizabeth: Yeah. So Women Who Code New York City focuses on junior, senior engineers and pushing them more into engineering leadership positions. So instead of focusing on the pipeline problem, we focus on making change within existing companies, and also within companies that we end up founding later on.

Suzanne: When you say "the pipeline problem," sorry, do you mean the problem of like being able to get a job as a developer? Is that what you're describing?

Elizabeth: Yeah. No, so when I say the pipeline problem, I mean the problem of getting elementary, middle, high school students into taking computer science as their main course for college.

Suzanne: Right. Okay. Got it. So you're not focusing on the bigger gap problem that we're talking about, although there are great organizations that are focusing on that, thankfully. You're creating space for women in particular who are already occupying engineering roles to have community and resource to advance.

Elizabeth: Exactly. The stat that startles me is that 56% of female engineers decide to drop out of the field, I believe it's five to 10 years after they have been a developer.

Suzanne: Why is that? I've heard about that as well. That's a big part of the problem. I mean, you're talking to these women all the time. Why did they leave?

Elizabeth: Yeah. It's a combination of microaggressions. It's a combination of, "Hey, looking for a job is really awful," and then the combination of, "Hey, we don't have enough advocates in the field that will just vouch for us." You hear about this all the time where you go to a specific college and you later on need a job, and anyone from that college will promote you or will get you into that company. It's a little bit different for development, which is of course extremely unfortunate, and that's why we see such a high rate of dropout for female engineers. We also see those engineers go into other fields, and I'm an example of that, of transitioning from being a developer into a product manager.

Suzanne: So do you consider yourself to be a traitor as a result of that?

Elizabeth: A traitor?

Suzanne: Yeah. Yeah. You're in engineering. You're helping to solve all the problems, and you're like, "But while you all are solving that, I'm going to be over here working as a product manager."

Elizabeth: No. I think I'm solving a different problem now. I really loved being a developer. I really liked working on a very specific application, and I think I had come to a point where I wanted to have a little bit more overlap across industries, across fields, between business and design and data, and I don't think I was unfortunately getting that as a developer, so that's why I decided to become a traitor.

Suzanne: Right. Okay. Okay. But do you still code to keep yourself relevant and able to have meaningful conversations?

Elizabeth: I do. I mean, every Friday I volunteer at a nonprofit called Nano Hackers. So we teach middle school students JavaScript, and so they're hacking on APIs right now, and that's like a really good feel-good thing for me to do, but it's also it keeps my skills partially sharp.

Suzanne: So actually in a way, you are kind of helping with the pipeline problem, just like in an indirect approach by creating a positive experience for young coders.

Elizabeth: Yes.

Suzanne: That's cool. That's really cool. Talk to us about the pivot into product management. So you're doing engineering. It's a very structured way of thinking about problems. It's a very structured way of approaching the solutions for those problems, and not a lot of engineers make that pivot. I mean, definitely many do, but when we think about all of the folks in what I call "PM adjacent roles", so that could be marketers, that could be business analysts, that could be designers, it seems more common that those individuals find their way into product management than it does for developers. So what was the catalyst for you, if there was one, or what were the circumstances? That's question one. Question two is: How is it different fundamentally as a product manager?

Elizabeth: Yeah. The reason that I switched into product management was because I sat in on a VC meeting, and it was a construction company raising their seed round. They were disrupting the field with their new brand-new platform, and it was going to disrupt all of the fields. Awesome. Unfortunately during that hour-long meeting with the VC, they never talked about the platform or about the technologies that they were using to build that platform, and me as a developer sitting in the audience like just watching them pitch this VC, it was frankly very disheartening. It was very clear to me at that point that if I wanted to raise a round of funding, get runway for any of my ideas, I would not be able to do that if I only had a technical skill set, because what they were discussing in that meeting was business, was the finances, the marketing aspect, how many users they had, and I did not have any experience with any of those aspects yet.

And so I decided to look for a different career, a career that would allow me to use my engineering skills, but was a little bit above the grind, looking at the tree and not seeing the forest kind of work of being an engineer. I found that product management, technical product management where I was manipulating a lot of the variables to ensure that a product was going to be built was a really good shift for me.

And so you asked why in New York City do a lot of those finance business people shift into product management as opposed to engineers. I personally think that those industries are very, I think you do need to have someone from those industries to gain runway for your idea, especially in the very early stages of your product. I think in the little bit of the later, mid-later stages of your product, you need a lot more engineering. You need a lot more technical ability, but your product needs to get to a certain point, and to get to that certain point you need the business and the finance aspects, and then once you get to that point, then you can move on and focus on building the best product possible, building a really fast application, making sure that all your data is stored correctly.

Suzanne: It's interesting that you're speaking about these experiences through the lens of an engineer, and of course it makes sense because that's the path that you started in, and I like that revelation that you shared of sitting in the room and going, "Wait a minute. No one is asking or caring about the technology. I got to figure out how to tell that other part of the story that a lot of people do seem to really care about." And, of course, it's not true that there isn't a time to talk about the technology, whether it's with VCs or others, but in terms of knowing the tech, in terms of being a founder, you hear a lot of times these business-oriented folks that you're describing say, "Well, I need a technical co-founder." Do you need a technical co-founder? I mean, if you are that person that possesses a really strong understanding of the business strategy, the marketing, the how it's going to make money, do you need a technical leader alongside you if you're building of course a digital or software product?

Elizabeth: Yeah. I personally if you can find a technical co-founder, a technical partner, I would absolutely say yes, but I do realize that we are rare beasts in New York City. I have personally known a lot of my friends who have worked at companies where they're going into series A, series B on, and the technical co-founder or the technical partner is very new to the organization, has only been there for the past couple of months, whereas the company has been going on for the past couple of years, and you can just see the technology not really taking hold within the business.

You can see this lack of technical understanding, and what that means is as you continue to spread your product to, frankly, other employees, the other employees just will always get the feeling that the technology is not at the forefront, and that's a very dangerous thought process, especially for a young company who is probably building a product that highly depends on technology. So if you start off with a technical co-founder, with a technical partner, you're going to have that embedded in your DNA. If you start off with them later, you're just going to be playing catch up.

Suzanne: Okay. What if I don't want a co-founder, but I subscribe to your advice and I want to bring somebody technical in early on? What is that role? Who am I looking for at that early stage?

Elizabeth: Looking for a senior developer. I think there's a lot of senior developers that do enjoy building a product from scratch and not having any past overhead of, you know, WordPress plugins that have gone horribly askew. So I think that there are a lot of developers that are happy, that do want to take on an early-stage startup. I personally think you also need to compensate them really well. You need to have also figured out your business strategy in the interim.

Suzanne: Right. But just to challenge this a little bit, the hard part for nontechnical people is finding and vetting technical people, right? Because we don't know what we don't know. So if you come along and you seem very lovely and you're like, "Blah, blah, blah, code and stuff and stuff and WordPress," and I'm like, "Great, Elizabeth, can you start today?" And just because you're a coder doesn't mean you're a technical leader, right? So even this idea of a senior developer, I think there is a difference between somebody who has good coding skills and somebody who can set that precedent for, or as you described, put the technology at the forefront and lead with the technology. So beyond just X number of years in engineering or these projects that I've worked on, what other aspects make someone a technical leader in your opinion?

Elizabeth: Yeah. The types of leaders within later-stage companies typically actually do not code as much. So if you're looking for someone with strong opinions on technology but who also codes, that's going to be a really hard ... that is very difficult to find. So you will probably get one or the other. You're going to get someone with really strong opinions on the tech that you should be using that codes a little bit, or you're going to get a developer that probably also has opinions but is not as management or leadership focused that codes quite a lot.

Suzanne: Yeah. I love that, the choice illustration there because you think about being top heavy, and I see this a lot in certain startup organizations that I consult where I'm looking around the room and there's a lot of founders, and I'm like candidly, "Who's got the value here in this room? We have too many people who know sales and not enough people who know anything else." But that can even be true where you go out to find a technical co-founder, but if you go too much toward a manager type, somebody who's more in the concept or more in the overseeing, and what you really actually need is boots on the ground, someone who's going to write that code. So that's an important distinction to be thinking about for our entrepreneurs who are listening in as we talk about these entrepreneurial challenges.

Elizabeth: And I know it's also very difficult when you're joining when you have that early-stage team and you're like, "Okay, well, we're at less than 10 people, so everyone is going to get some sort of 'exec' title," I'm doing air quotes here.

Suzanne: They can't see, but she is in fact doing air quotes.

Elizabeth: And what you would call a senior developer is your CTO, and often that's what you're going to call the developer who signs on the bottom line that has five-plus years of experience, but early-stage CTO is a very different role than senior developer. Not even in the equity terms. CTO means that whenever you're raising your round, the CTO is going to come with you at the very least of all the changes.

Suzanne: Right. Yeah. No, these are all important details I think to consider. You mentioned before you said there's not a lot of technical product managers in New York. Well, actually you spoke about the technology not necessarily being as much at the fore in a lot of startups that you've seen here, and there not being a lot of technical product managers. Why do you think that is?

Elizabeth: I personally think that New York City as a technology scene is still growing and is still very nascent, and therefore a lot of the product managers that we have in New York City are transferring in from other fields. Heck, I'm definitely, I'm a transfer. I did not start off my career as a product manager. I started off my career as a software developer and then switched into product management, and I don't think that the number of software engineers that are switching into product management are as many in New York City. So technical product management is not a specialty that I've found in New York City. I found a lot of product managers with a background of sales, with a background of an MBA, finance, but not as many technical product managers.

Suzanne: This is actually an advantage for you in the marketplace because then you're the real commodity. Soon, everyone will be a technical product manager, but for now people should just contact you directly. What does it mean to be a technical product manager? We understand you came from code, so just sort of by default you have technical acumen, but if I'm hiring for this position of technical product manager, what is it that I should be expecting that to include as kind of like core skill sets?

Elizabeth: So a product manager in general, I think that this is a pretty standard definition, is a translator. It's someone who's creative and is someone who's a translator within that respective field. A technical product manager is someone who can translate whatever technology tools the developers are using and be able to tell the business about why they should be paying $1,000 a month for a Jira subscription. That sort of translation there, that sort of cost-benefit analysis broken down by the developer is I believe the biggest selling point there.

Suzanne: Right. And so this question comes up a lot, like, "How technical do I need to be?" So let's say I am one of these product managers here in New York that doesn't happen to have that technical acumen, but I'm either listening in to this conversation or I'm starting to sense that that is a weakness in my kind of toolkit, or as I hear all the time, "I'm applying for a job at Amazon or Google, and they want technical product managers." What do you think are the essential things that I should know and/or learn in order to kind of gain that confidence or be able to declare myself a technical product manager?

Elizabeth: Yeah. I mean, I think it all starts from a place of empathy. Like as we're sitting at Civic Hall as we're talking about Women Who Code, it all comes from a place of empathy, and it's empathy for the software developer. The software developer are mysterious creatures, and they roam very freely in New York City, and they just want their tools to be understood. They want their voice to be heard, and I think there's a number of tools that they use that should be better understood, that should be better articulated to the business. Their specific way of thinking should be better articulated to the business.

So my personal like quick sheet way of becoming technical is I would probably go to a software development meetup in New York City, there's to dozens every day, and try to grab a junior developer, a mid or senior developer if you can, and work with them on a project. I think that there is benefit both ways. You can learn about what tools they're using, what process software development is, and on the flip side they can also learn what a product manager is. Developers are often very confused by what project managers do in general as well.

Suzanne: So if I go to these meetups, what do I say to the developer? What's my pitch?

Elizabeth: Your pitch is, "Let's build an idea. Let's build an idea. You have an idea, I have an idea, let's build something together." It can be something really small. I know someone who's building out a website application that imported the Google Earth API and also used it to like combine that with like the weather, so you clicked on a specific place on the website, you clicked on Morocco, and it would tell you the weather for that specific location because it also took in the weather API. And I was like, "Oh, that's a really cool thing you're doing." Probably took both of them a couple of days to do, and you would learn so much about that. You just need to get started and start building.

Suzanne: Right. Cool. Do I have to just sit quietly and watch and ask questions? Because I always joke I can't imagine developers enjoy having somebody standing over their shoulder. Do they?

Elizabeth: You know, there's this concept in software engineering called "rubber ducky". Have you heard of this?

Suzanne: No.

Elizabeth: So when software developers have a problem and they find a bug in their code, they can't figure something out, they will typically like take their laptop, unplug all the cords, and go to the next software engineer and be like, "Okay. Well, here's all my code that I've just written, and there's a problem. How do I solve this?" But the act of them explaining what their code is often causes that software developer to figure out what the problem is. And so, hey, instead of wasting someone else's time, why don't you have a rubber ducky at the side of your desk and explain what the problem is to a literal rubber ducky. I think software developers are actually quite used to explaining the process of their thinking to themselves or to a plastic object. Yeah, I don't think they would mind too much.

Suzanne: I think what you're saying is you would be the rubber ducky to their process and they'd be grateful because when they run into a brick wall, they would turn to you and say, "Blah, blah, blah, blah, blah, blah, blah," and then the light bulb would go off in their head and they'd go back to coding, and you'd feel as the product manager that you've contributed value somehow. You're like, "I didn't do anything, but I'm glad I was here."

Elizabeth: I mean, that's the hope. You're going to like feel hopelessly lost for the first like five hours, but that's the point, right? You have empathy for this thing. You want to learn how to be technical. You're going to feel lost, and you just need to grapple with the feeling of being lost and go home and Wikipedia a bunch of YouTube articles and watch a bunch of videos and then you're done.

Suzanne: Cool. All right. I want to go back to something that you said earlier about kind of the theme or the goal of Women Who Code in New York, which is it's about helping female engineers in particular I think stay vested in the process and be successful, and not in the context of building their skills specifically but actually having success in their field. Everybody knows there's a gender problem in tech in particular, and everybody knows that that culture is often a culprit for creating kind of untenable conditions for female engineers. So if I'm a founder or a production leader and I want to build a team and I want that team to be diverse and I want that team to have good morale and I want it to include women and I want it to include men, I want it to be diverse, how do I do that differently? What do I need to do differently as a leader to be able to create that environment?

Elizabeth: Yeah. I think ... diversity builds diversity. So if you are a white man building your startup for the first time, I think you have to be very patient and try to find a partner that matches that diversity, because otherwise if you ... You're going to hire someone who probably 80% chance looks like you because that's your first network, and if now you have two people who look like you, well, it just grows and grows and grows until you hire your first like assistant, and then the diversity question starts to appear. So I think you have to be patient if you are not diverse, and you have to reach outside of your first round of connections.

Suzanne: That's such great advice, and it's about being uncomfortable I suppose in that. Well, I think what I'm hearing you say is it's about being deliberate in being uncomfortable, because the easy thing to do is just go to the people that you know and then, as you say, you could very quickly become that kind of frat culture, bro culture that people talk about all the time, so deliberately saying, "No, if I'm a male, I want a female on my team. If I'm white, I want someone of color to kind of come and help bring different perspective."

Elizabeth: And I also realize that that's, there is a trade off. I'm asking for patience, and that patience is coming at the expense of your startup growth. I do understand that at the very beginning it's an A or B question, like, "Hey, you can hire person number one and they can do the job reasonably well and I can hire them tomorrow, or I can be patient and I have to wait for person number two, and person number two will probably take a month or two. But if I am patient, I know that my product will have far more edge cases, will probably appeal to a much wider audience, and therefore in the long term I will have a much bigger business if I am patient for that first couple of months and find diverse employees from the beginning."

Suzanne: Awesome. Sound advice. We do a segment here on the show that's all about advice. It's called Get the Job, Learn the Job, Love the Job. If you're game, I'd like to ask you a couple of these questions.

Elizabeth: Okay.

Suzanne: Cool. So what advice do you have for somebody, a developer that is looking to get into product management and sort of make that leap into the more strategic center?

Elizabeth: I think that there is a wonderful program that Civic Hall runs called Delta NYC that gives developers a chance to work on a project with a product manager, with a salesperson, with a marketer, and I think that the first thing you have to understand is what a product manager does before you can be one. So if you look for projects that you can join, that would be a really good way for you to start to understand what they do.

Suzanne: Okay. Reverse rubber ducky.

Elizabeth: Reverse rubber ducky.

Suzanne: What about hard lessons learned? So you started into product management, and now you're a little bit out of your element, right? You're trying on a new lens, you're trying on a new set of problem-solving capabilities. Where have you struggled on the job, or can you think of a specific maybe mistake that you kind of encountered that you thought, "Oh, that caught me off guard, okay, next time I'll know to avoid that pitfall"?

Elizabeth: Yeah. I think a lot of the product problems I've had have come from not listening to people. One example of that was where I had my team of developers and they were telling me quite clearly that they wanted more product input, but I was listening to my founders, and my founder said, "Eh, this is the actual way that we're doing this," and I should have been able to feel the frustration from both parties and been able to meld both of that together. So I think the pitfall always comes back to listening and understanding people.

Suzanne: Yeah. In anything in life.

Elizabeth: In anything.

Suzanne: What do you love about product management?

Elizabeth: I love the ability to just scope out a project from the beginning to the end. I feel as a developer I was going straight into the building of it and I was not allowing my mind to go a little bit above and been like, "Okay, well, let me break all of this down, and how would I market this, and how would I get users?" So I love the building aspect of product management. How could we build this thing? Sure, let's definitely look at the developer tools, but let's also break down how we would get the users and how we would make them stay. That's the exciting part for me.

Suzanne: Yeah, yeah. The visual that comes up in my mind is you have to and are able to start asking questions more horizontally than the limited scope of questions that you can and should ask in the context of building it, right? It's different sets of questions. Same kind of mind muscle that's being flexed.

Elizabeth: Yeah. So it's more about the row versus the column.

Suzanne: Very well put. What about recommended resources? Any books, blogs, podcasts, meetups here in NYC that you think have been impactful in your own personal growth or that you just think are great things to digest?

Elizabeth: Yeah. I went to an Agile experience meetup a couple of months ago and I loved learning about the Agile design methodology, because I've been doing the Agile design methodology for years, but I've never looked at it from a design perspective. I think New York City has a fantastic meetup culture. Women Who Code New York City I think has probably one of the most high-quality meetups for it being free. People come up to me at Women Who Code and are like, "Wow, like I can't believe that this event is free. I pay for events, and normally like $20, $50 events are not this good."

Suzanne: Wow.

Elizabeth: Women Who Code New York City is what I would recommend.

Suzanne: Yeah, yeah. Plug it, absolutely. Absolutely. I mean, I think what you're doing is great. This is the last question for you, Elizabeth. Is there a personal or professional mantra or philosophy that you hold dear and that just guides you in the world in how you like to be and how you like to operate that you want to leave us with?

Elizabeth: Sure. Break it down and build it. It means if you have an idea, break it down into its smallest component. What's the most valuable product that you can test it to get it done? And then see if there's traction. It doesn't even have to be here in New York City. There's so many ideas that are culminated in China, in India. I recently had a friend who came from Nigeria. There's so many international ideas. If you have an idea, break it down, build it. It does not have to be here in the United States.

Suzanne: Great. Pretty memorable soundbite: break it down and build it. Elizabeth Ferrao, Women Who Code NYC. If you're listening and you're in New York, if you're a woman and you're an engineer, go and be part of this amazing community. Thank you for being on our show.

Elizabeth: Thank you.