Office Hours with Ellen Chisa
We're excited to introduce our new series, Office Hours, where we interview leaders in product, engineering, and design about growing your career in tech. Our first guest is Merit investor and mentor Ellen Chisa.
Ellen Chisa is a Partner at Boldstart Ventures, angel investor, and engineer. She created Dark, a programming language coupled to its editor and infra. Previously, she was the first employee at Lola, combining the best of technology and people for travel planning. She also worked on Kickstarter, and early versions of cross-platform Office Mobile.
Below is a transcript of our conversation, lightly edited and condensed for length and clarity.
Rachel Spurrier: You’ve had a variety of roles throughout your career. You’ve been a product manager, a Harvard Business School MBA candidate, founder, and venture capitalist. What advice would you give to someone whenever they’re doing a role for the first time or are pivoting onto a new career path?
Ellen Chisa: That’s a great question. I love doing a new role for the first time. I think it’s one of the most fun things. There’s a tension where you want to make sure you’re learning enough up front to be effective and not be the person who runs and shouts, “We should do it this way!” without knowing anything.
But at the same time, you want to start taking at least small actions relatively quickly to show your impact, especially within smaller organizations, because otherwise, it’s like, “Why are you in here if you’re not also contributing?” And so I like to do this balance of “What is the smallest thing I can learn to figure out what to contribute first?” and then build that up over time to have it be more of a learning-contributing cycle.
RS: For someone who’s never done this [role] before and is maybe encountering some form of imposter syndrome or fear, do you have any ways to combat that initial, “I’ve never done this before” or “This is new to me”?
EC: I am probably not the right person to ask this question. This morning I, for some unknown reason and in a block of time that was only 45 minutes long, decided to try to make Meyer lemon pôt de crème for the first time, which worked, I think. I won’t know until tonight, but I’m pretty sure it works, but I’m very much like, “I will just run headlong into something.” And I think that’s fun.
Probably the thing that helps me the most is at the end of the day, it doesn’t matter. A lot of the things we think of as being risky or being failures don’t actually matter at all, like when you show up at a job and it doesn’t go great.
Maybe it wasn’t the right job and you do a different one, or maybe you make a mistake and you learn something. But I feel like almost every decision we make career-wise can also be undone and you can go do something else. We’re often much more self-critical about it than other people would be of us.
On top of that, we’re paying a lot more attention to what we do than anyone else is. Just going for it and trying—we underestimate the cost of not trying because we’re so worried about the things that might go wrong. It’s much worse to sit there and do nothing than it is to just go for it.
We underestimate the cost of not trying because we’re so worried about the things that might go wrong. It’s much worse to sit there and do nothing than it is to just go for it.
RS: I’m so glad you brought [career decisions]. Speaking of which, I’ve read your writing and you do a really great job articulating frameworks for thinking about problems, whether it’s a technical problem or a career problem. What frameworks do you like for thinking about career decisions?
EC: One of my coworkers was asking me about this. His [question] was more of like, “Where should I live?” And he was thinking of what framework to think about that in. With career decisions, I try to think through what are anchor points first. You might say, “At this phase of my career, what really matters to me is comp.” Especially if maybe you grew up without financial stability, it’s important to you to get to where you feel stable or you could help your family.
Mine personally has mostly always been optimizing for learning and to a lesser extent trajectory of “How far can I go? How fast?” which means I’ll give a lot of things other people won’t give up. I will happily move to any location in the entire world if it means it’s a cool opportunity to learn something. It doesn’t matter to me. It’s not part of the calculus.
It might be something like growth. It might be something like wanting to work for a specific person to learn a skill. Especially if it’s a new type of role, your manager could have a huge impact on that. There’s definitely been jobs I took because I wanted to work with a specific person. My team now at Boldstart is a great example of that. I wanted to be able to work with Ed and Eliot and Shomik and Natalie, all of whom I respect a ton.
I would think about what the most important thing to you is first and then slot in everything after that. A method a lot of people use that I don’t particularly like is making a spreadsheet and assessing every job on every factor. I guess it kind of works if you weigh the factors, but at the end of the day, I don’t think there’s really a mathematical thing for me. There’s one thing that matters most, and I’ll probably make the decision solely based on that.
There’s definitely been jobs I took because I wanted to work with a specific person.
RS: I think the point about learning is really interesting. One of the things that we get a lot of at Merit is questions about transitioning roles, either from product managers to software engineer or vice versa, or “I want to break into tech.” Do you think that this is a new trend of how many people want to break into tech or move disciplines within tech? Or do you feel like that’s something that’s always been the case?
EC: I don’t think that’s always been the case. I would say it’s probably been popular for the last decade. The reason I started writing, to begin with, was when I first started working at Kickstarter in 2012, 2013, I got so many emails from people who wanted to chat about becoming a PM that I was up to multiple coffee meetings per day to try to solve this mentorship problem. It was exhausting, and that’s part of why I like Merit, because you can rate control that sort of thing.
So at least by 2012, 2013, that was definitely happening, and I think it makes sense. It’s an industry that’s relatively well-compensated. I think a lot of the roles have a lot more flexibility compared to say, being in banking or retail or something with a more strict schedule.
I think another part of it is there’s been a lot of hype around, “Get retrained in 12 weeks, then you can work in technology,” which I think is quite overblown. We should also be realistic about all the sacrifices people have to make to be able to make that transition.
RS: That’s really great context to have. I’ve thought about writing content on those topics for Merit: “So you want to be a PM,” “So you want to be a software engineer.” And we do hear a lot of people ask, “Where do I start?” When you’ve got that question about, “How do I become a product manager?” how did you tend to answer?
EC: There are a fair amount of people who would come in and say, “How do I become a product manager?” And I would ask them why they wanted to, and they would say something like, “I want to be in charge”; “I want to have one of those cool tech roles, but I don’t want to learn anything about having to code or do design.” That kind of weeds out half of people—from those underlying motivations, those people shouldn’t be product managers. I think it would be quite the slog to get there without having those other interests.
Once you are interested in product management in particular, it’s best to lean on an area of strength. So if someone is coming in from another industry background, I’ll encourage them to think about startups that are in the space that they were working in before that has led the domain expertise. I’ll also encourage them to think about other roles that will allow them to move laterally. It’s much more common to see someone move from an engineering role to a PM role or from a support role to a PM role than it is to see students get hired into their first PM job. Frankly, no one really often has the bandwidth to train PMs who haven’t been PMs before, so you often need a little bit of that social capital within an organization to be able to get into the role.
We should be realistic about all the sacrifices people have to make to be able to make [a career] transition.
RS: I completely agree. That was my experience with product management. I’m no longer a PM, but that’s exactly how I became a PM—as a lateral move within an organization.
In terms of software engineering, you did bring up 12 weeks of retraining, and I believe you were referring to bootcamps and the kind of caution attached to them. For people who would like to get into coding or become software engineers, what do you think are the major considerations or potentially even pitfalls?
EC: Yeah, it’s tricky. It’s hard for me to necessarily say because I did robotics in high school and then I went to engineering school, so I had a fair amount of technical background even starting out. I still didn’t think I was a great software engineer. I think I’ve improvised a lot just through professional work and doing stuff on the side.
One pitfall is there’s a huge gap between doing coding puzzles or read a “learn python textbook” or if you went to Project Euler and started doing algorithm challenges—those are fun puzzles to solve, but they’re within a constrained environment. You’re really only thinking about the code, whereas I think a large amount of the complexity that happens in most companies today is more around the infrastructural components—like making sure your development environment works, being able to read other people’s code, being able to contribute to a codebase that already exists, and then actually getting stuff into the world.
From that perspective, I would say to try to make things as pragmatic as possible, even to the point of possibly focusing on a technology that’s relatively popular and has a strong community. I think most recently, most people try to get started in JavaScript, usually the React flavor of JavaScript. That’s not a bad idea when you’re trying to think about how much you’ll be able to get support and how many jobs will be available doing this directly.
A large amount of the complexity that happens in most companies today is more around the infrastructural components—like making sure your development environment works, being able to read other people’s code, being able to contribute to a codebase that already exists, and then actually getting stuff into the world.
RS: That makes so much sense. When I spoke to engineering managers about what they would recommend to bootcamp graduates, that’s exactly what they said—that in general, coming out of coding bootcamp, you know how to write code, but do you know how to work in a production-level system? Can you submit a pull request; can you understand why something might not be working and do basic debugging?
You’ve spoken a lot about different people who’ve reached out to you whom you’ve mentored over the years. Has the role of mentorship changed in the past 2 to 5 years? If so, how?
EC: I think the role of mentorship changes more depending on where your career is. So if I were thinking about the last two to five years, I would say it's certainly changed, but I think it's also that I have changed in the last two to five years.
When I tend to think of how mentorship works well, I think people have become more aware over time that often the people with the best perspectives on the challenges you're facing now are a few years ahead of where you are. If you're trying to break into product management, the person I would go to is somebody who's been a PM for a couple of years. If you're an early career PM, say two to four years experience, and you're really thinking, “How do I get to senior?” I would go to someone with 6 to 10 years of experience. If you're 6 to 10 years in and you're trying to get that first director job, I would go to someone who's recently become a director. There's been more emphasis on that: find someone a little bit further rather than everyone saying, “I want the CEO of the company to be my mentor.” That's not going to work out too well.
There's also become more awareness of the difference between mentorship and sponsorship. Merit is a great place for mentorship where you have that conversation with someone and you want to be able to work at one thing, and then you're going to take action. Historically we use mentorship within organizations to cover for not having sponsorship or people being put forward for opportunities.
Often the people with the best perspectives on the challenges you're facing now are a few years ahead of where you are.
RS: How would you describe the difference between mentorship and sponsorship?
EC: Mentorship is being available and being willing to talk to someone about their career and maybe giving them suggestions or advice. Sponsorship is helping put them into situations to give them an opportunity that they would not have been able to get for themselves. [Sponsorship] is using your social platform to give them an opportunity that wouldn't otherwise exist either by passing on an opportunity or submitting their name when someone asks you for a speaker or a candidate for a job. You’re putting yourself on the ledge somehow for this person.
RS: On the mentor side, some Merit mentors are new to mentorship. This is their first time being a mentor. Maybe they’re trying this out to see if they’re interested in the management track, potentially. What advice would you give to someone who is being a mentor for the first time?
EC: I've gotten very into this topic for some reason. A lot of people underestimate how much when they give advice, they're actually giving advice to their past selves. They hear what the person who's asking for advice says, but then they put this entire other layer on top of it. Then they answer that: the other person plus their lens. They do those two together.
As a mentor, practice going like, “Okay, this other person isn't me. And I'm going to try really hard to only answer what they have given me and not project a bunch of stuff on top of it.” It’s something that's hard to learn, but very worthwhile because it applies in a lot of scenarios that aren't just mentorship. Mentorship is a good way for potential managers or managers to train themselves in that skill.
A lot of people underestimate how much when they give advice, they're actually giving advice to their past selves.
RS: I read about that in your most recent Substack article. How do you try not to do that [giving your past self advice]? Maybe with the founders that you work with or the folks whom you mentor, what is your way of avoiding that pitfall?
EC: I don't know if this happens to other people, but usually when people tell me a story or a company or a situation that's going on, my brain will quickly pattern match it against something else that has happened before. I try to never just take one of those. I'll try to find at least two or three more that I think matched the experience. This requires being able to trawl your memory archive pretty fast, but being able to triangulate it helps. Even if you only have a couple of stories, being able to think about “What were the most important parts of those stories?” and then try to gauge from the other person if those are also true in this case—asking clarifying questions before jumping straight into advice.
RS: Is there anything that you would recommend in terms of skill-building or skill acquisition, whether it's learning a new coding language or trying to learn how to create a product roadmap for the first time?
EC: I like to practice learning how to learn. I think you should always be learning something new and thinking about how that works differently than something else. I took a poetry writing workshop with a friend recently, and then we've been talking about doing another non-fiction essay, narrative-shaping class. I've taken painting before. People underestimate that learning itself as a skill. The more things you can do that stress how you learn and teach you new ways of learning, I think is the highest leverage thing you can do.
I like to practice learning how to learn...Learning itself as a skill.
RS: I read your article about managing up and I thought it was so interesting, particularly talking about managers of product managers. In general, I think for people earlier in their career, learning how to interact with their managers actually pretty difficult. I don't know if you agree with that assessment, but if so, what, what would you tell someone who is learning not only how to manage a manager, but just how to interact with a manager?
EC: It depends on how big the company is. I think a lot of people, particularly at the IC [individual contributor] level don't understand that—I would guess any large organization—the line manager job is the most stressful of jobs. Because if you think about being a director, where you're managing managers, those managers have empathy for you, because [managers] also manage. And [directors] also are at a point where [they] have a little more sway about the organizational direction, usually, whereas that second, line-level manager usually doesn't. I would really encourage people who are early career in a large organization to understand that as much as their manager seems important to them and the great scheme of this organization that has 7 to 10 levels of hierarchy, their manager really is not actually wielding that much power. It’d probably a pretty rough space a lot of the time, and [your manager] can't tell you.
More pragmatically, it's more about—I feel like part of this is trial and error—but being open without being too open or being upfront without being too upfront. I think the way you frame things is very important. So it's like, “Okay, I hear that the priority is whatever. Can you tell me more about this priority?” If the organization is large enough, it's probably not going to matter if you disagree with that priority or not. Either you get on board and learn how to execute and be happy doing that in that context, or switch jobs. But you probably can't change it. But within smaller organizations, maybe you can.
RS: I like that you brought up the “whether or not you’re happy executing on those things, and if you’re not, maybe move on to a new job.” A lot of the questions that I see on online communities is, “I started this job and I hate it. Can I leave?” I saw in an interview you were talking about this. I often feel like folks are asking for permission to leave a job that they don’t like or are unhappy, for whatever reason. Do you have any advice on ways to make that decision to stay or to go?
EC: It depends. If it is your first job ever—I think I did my entire senior college final project on transitioners, who are people who graduated from college and going to work for the first time. If it's that job, you should stick it out for a year because I think there's so much different that happens when you're leaving the educational environment and you're going to work. You have a very different schedule. You've likely moved to a new place or at least a new apartment and are learning to be an adult in very many ways. In that case, a lot of the angst tends to not actually be about the job, just from what I've seen in that research.
On the other hand, I would think of it almost the way I tend to think of it as a manager: when you hire someone, you should be trying to set them up for success within 90 days. I try to do a 30, 60, 90 check-in. And if someone's not going to work out within the organization, I want to figure that out within 90 days and have them move on to somewhere else.
As an employee, similarly, a lot of people are like, “Oh, I took this job. I have to keep it. I'm going to stick it out.” But if you know within two months that no, you’re not staying here, leave after two months. You're better off having that two months, frankly, especially with the way LinkedIn displays things. If you only stopped your other job the month before and you have a new job the month after, it won't look like a gap at all. No one's going to ask about that. You could have just taken off three weeks between your jobs. That's going to be better off than if you leave after a year.
What if you get it wrong again, then are you going to do the same thing where you're gonna stay for another year? Then you have these two [jobs] that are only a year long, which can—I know there's a lot of talking if this matters or not, especially for underrepresented people, leaving bad environments—but many hiring managers will ask you about two one-year stints in a row. You don't want to have too many jobs where you have to explain that you were unhappy again at another job. So I would say you should make the hard call early.
This last question was answered via email.
RS: If someone is experiencing, "I started a job; I hate it; I want to leave. But I want to make sure that my next gig is a better fit so I don't have back-to-back short stints." What can people in this situation do in the interviewing process to assess if their next role will be a better fit?
EC: I think the key is being honest about yourself with what you will live with. Every job has problems so it's unlikely to find one that won't have issues—decide which ones are okay or aren't okay with you upfront. Ian McAllister wrote a good piece this week on avoiding missteps.
To hear more of Ellen’s thoughts, you can book a mentorship session with Ellen on Merit.