IC? Manager? Technical Founder? How to chart your engineering career path — Stripe & Cocoon’s Amber Feng

 So we're going to spend the time together talking about all sorts of different facets of, uh, growing as an engineer and engineering leader. And I thought a place we could start, um, it might be to explore some of the things you've noticed, in terms of what makes somebody a top 5% or 1% engineer relative to other folks.

 I think that one thing that people don't talk about as much when they talk about great engineers, um, I think there's a lot of emphasis on writing code, designing systems, uh, building products, and that is all extremely important. I think that something that people don't talk about a lie is like, good communication and writing in order to have the right kind of impact. For me, it's actually totally underrated. I think some of the best engineers that I've worked with are not necessarily just the folks who are good at writing code are good at designing systems. I think the best engineers are often the ones who can even figure out if they're building the right thing at all the folks who can think through a problem really deeply and who are really rigorous and curious about what is most impactful for the business and how they can have that impact as well.

 And so one of the things I thought was really interesting about both striping cocoon is that both have very strong writing cultures actually. And I think writing is extremely important. It's one of those things that forces people to think really rigorously about what, what they're doing, because they have to write it out, um, in a very concise manner to, to convince others, but also is really important for like posterity and knowledge sharing and enforces.

You just like really understand what you're doing.

 Do you think that that's something that someone can get much better at, or it tends to be kind of people are wired in a certain way. 

 I think it is something that people can get much better at. I feel like I basically learned how to write at Stripe, um, by watching other people or reading things that other people have written that I thought were expressed in a very articulate way. And I, I guess by the way, when I talk about communication, I'm not just talking about like, being good to work with, like in an immediate sense with your immediate teammates on a project.

I think that can get you a certain amount of distance, but. I think that some of what is really important to pick up, which I do think is very learnable, is figuring out how to actually convey the things that are most important. So getting good at concise summaries, for example, like updates, like blockers, like highlights, risks, et cetera.

And then also kind of like learning how to read the room in some sense, and understanding your audience, especially when you're kind of building from zero to one. A lot of you might be a lot of, it might be working with folks who are not engineers, where you're talking directly to customers. Um, you're whirling a lot of different hats.

And so a lot of that, I feel like I learned a ton of actually on the job. I don't know if I was great at it before

 And when you think about folks trying to develop these competencies, do you, you sort of mentioned like one tactic is just observing what great looks like in these two areas. Are there other things, or when you think about engineers that you've coached in this area, um, other things that they can be doing to kind of get up the learning curve. 

 I think one tactic I've often coached people on is maybe this is somewhat when it comes to like reading the room or understanding your audience. I think when you're writing up something, whether it's a doc or it's like a shipped email or, or anything on announcement, um, or just like even a kickoff, I think thinking about what the likely FAQ's are going to be like, what are the questions that are going to come in and then actually just anticipating those.

Um, so Sam writing the design doc, I'm writing out the milestones for a project or I'm explaining what the goals of the impact should be. Then I kind of ask people, well, what do you think are the FAQ's for this? And actually just like write them up ahead of time. And so when you force people to go through that kind of like thought exercise, I think they start to think more deeply about, okay, like, let me put myself in the shoes of somebody else who's reading this email, or let me put myself in the shoes of, a customer.

And then how are they going to think about this? And I think that really helps clarify some thinking. And then also kinda makes you distill down the essence of what you're trying to say and, and do that upfront. Do,another way to get at the same idea would be Are there other things, when you think back to the best writing that you've done, or that teammates of yours have done? Like what, what makes it so good? 

 if I think about the best writing, I think a lot of it besides being concise and, and getting to the point, I think a lot of it is sort of like bringing folks along and helping them understand the decisions that you've made.

 So, I mean, maybe this is another theme that as the team grows, I think there is this big learning or theme about figuring out how to scale yourself and your decision making one, you're an early part of a team. I think you've built a lot of the foundation of the code base and the architecture.

Sure. But I think more importantly, you've built the foundation of like the team conventions and the culture and what's their quality bar and how should others be approaching things. And I think a lot of the essence of that is like, how do you capture that so that they propagate throughout the team. And so for example, one thing, that I tell folks about is like, if you find yourself being a bottleneck for something like reviewing product, or I dunno, reviewing code changes or reviewing copy, like try to distill down.

The, like what the actual product principles are or what your framework is. And this goes for true for any kind of decision-making framework as well. So I think maybe going back to your question of like, what makes the best writing is sort of not just conveying, like the point of like what we're trying to do here, but also bringing folks along, like helping people understand, like how do we actually make the decisions that we made, or anticipating the questions that might come up and then helping people be able to make similar types of decisions in the future.

 are there other things that you think might be underrated or overlooked when you kind of dissect the best technical folks that you've worked with? 

 I think for me at the end of the day, it really comes down to impact and impact on the product and impact on the business. I think when we talk about engineers, I mean, we're not just talking about engineering skills, right? We're talking about folks who sure are excellent from a technical perspective and maybe from a product perspective, but who are always thinking about how to actually have the most business impact at the company So as a founder now, I think this is actually a lot of what I think about for folks that I'm team on my team and what I'm hiring for. So I kind of often say that I'm hiring entrepreneurial generalists, right? People who are entrepreneurial in the sense that they want to think deeply about the problem they're solving.

Again, not just from a technical perspective. The question from a perspective of, are we even doing and building the right thing here who want to drive kind of big projects end to end and also scale themselves? And so I think some of those aspects tend to be, I think, more underrated where there's a lot of focus, 

Around, can you ship code quickly? Can you design like the most scalable or robust system? But I think there is very much of this question of, can you drive the actual impact that you want? And some of the impact might not come from solving a technical problem it might be like an organizational problem, for example.

And so when I think back to the best engineers that I've worked with, or Beth engineers at Stripe early or early on, or even cocoon, are there folks who can really do that?

 And when you think about team construction, do you want everyone to fit that mold or do you want people that?

spike in different areas and maybe somebody that's more problem or product oriented paired with somebody that's more execution oriented? Or is it a thread that you kind of need to everybody to think about the world in this way? 

 Um, I think it really is kind of what you're saying about the composition of the team, I think very early on. So if you're talking about like the first, like three hires on the team, I think it is really important that everyone can kind of play this. Like end-to-end wearing all hats role because when you think, when I think about what problems we started doing early stage shirts, it is building product.

But a lot of times we didn't know what we were building. Right. We had someone has to go sit on the sales call, figure it out, distill it from the operations teams, um, and actually talk to customers. I think there's a lot of ambiguity. And so I think that maybe that's a better way of putting it. I think you really need people who can work within a broad range of ambiguity.

And those tend to be people who have more of sort of like this end-to-end notion where they're trying to solve a problem. They're not just trying to build this.

 I think you articulated, uh, a really great point about. What makes someone particularly great as an engineer? And I think it's the sort of, what I heard you say is that I think it's the ability to be quite broad in the scope and span of actually what they're responsible for and to think about things in terms of, uh, outcomes or problems or products, as opposed to.

 APM or someone tells you to build a widget and you just go build the thing that you were told to go build. if someone is trying to develop that or someone on your team, you gave them feedback that this is an area that they are weak at. what advice would you give them to remedy or what should they work on or what rituals or habits should they develop that maybe they don't currently have. 

 I think it's twofold then. some of it is really just, how do you build the right intuition about this? And some of it is just simply being able to pattern match off of things that you've seen before. And so. It is the pure experience of being in the room where it happened or in the war room and seeing other people, um, drive projects in a way, and being able to actually examine what made their communication or what made the way that they drove their project, like especially great.

 Um, so I think there is a observation of like, how do you get yourself in the right roles or companies or position where you're really feeling like you're learning, um, from people who are great at what they do and being able to observe that. I think the other part is kind of maybe that like willingness to kind of throw yourself in the deep end.

Uh, I think a lot of the places where I feel like I grew the most was when I decided that I wanted to be on the steepest learning curve possible. That's like one of my life philosophies in a way. And I actually remember when I had first joined Stripe, and I was working on my set of kind of onboarding tasks or spin up projects.

Um, and then the person I was working with was like, okay, for your next set of projects, like, why don't you choose between these four? And then I guess I had asked like, okay, well, which one is the hardest one? Like I want to do whatever the hardest one is. And so I think there's a little bit of like willingness to throw yourself in the deep end, um, to like take on that challenge, knowing what you actually want to be learning.

Right. Um, rather than sticking to something that may feel more of like your comfort zone, but then you kind of don't get the opportunity to stretch or like step up in the right way when you are challenged.

 exploring a slightly adjacent topic. I'm curious, given some of your thinking around. makes a really great engineer. What are the types of rituals are part of the ways that you approach building things as a team that maybe increase the odds that people can operate in that way or see the world in that way?

 Like an example for me is I think that one of the simplest things you can do when you're doing anything in business, even outside of engineering is just constantly going back to what is the problem that we're actually trying to solve and whose problem is it? Because I think that we in most companies like to solve the company's problem and not a customer's problem.

And I think that that is like a thread that ties a lot of bad things together. Um, and so I'm curious when you think about the way that you, you operate and it could be a Stripe, it could be a cocoon. Now, what are the Maybe rituals or the way that you actually build software that might.

 Yeah, actually, I think it was exactly what you were just saying, Brett, which is almost put yourself as close to the customer or the end user as possible engineering is not a vacuum sort of like you're building it for some reason. Right. So what are you actually building it for? And so like, literally go find your user, sit next to them, watch over their shoulder, see what they're doing.

Right. I mean, you can hear anecdotally from user research or like see from. I don't know a product brief, uh, what the problem is, but I feel like there really is no substitute for just going out there, like jump on the sales calls, listen to what people are saying, listen to what they're concerned about.

Talk to customers, walk through, watch them, use the product, see what buttons they're clicking, what they're not clicking, what flows they use, what they're confused about, or even applying to internal tools where your internal customers, um, like go sit next to someone, literally try to do the thing that they're doing, right?

 thing that we spend a lot of time thinking is like, how can we do more like rotations? Like at Stripe, we had, um, all engineers on support rotation, uh, in the very beginning, I think we were like, literally get paged. Uh, if somebody was asking a question and hadn't been responded to.

 And so when we think about building either products or internal tooling or like automations, whatever it is that we need to like actually get the impact, it's really truly being steeped in what the problem is. And oftentimes it means doing it yourself.

 how has your experience at Stripe, influenced the way that you think about the roles and responsibilities of the engineers versus product managers? 

I think early on Stripe, maybe infamously or notoriously did not have product managers. I think there was a thinking early on that, I mean, a lot of our product was built for engineers. Like we're developer API, that, that obviously changed over time. so we were engineers building a product for engineers and then just like wanting that feedback loop to be as fast as possible.

 Right. So I would actually be G chatting. This was before slack existed of EG chatting our users, asking them what they thought about us or an API be like texting them, like et cetera. And having them just like use something and that they think this goes back to a lot of this conversation of like, how do you put yourself as physically, or I guess in today's world digitally as close to the users as humanly possible.

I think that w at Stripe where we started to find that we were really missing a role for, for example, product managers, or maybe it's like a biz ops role or something else is a lot of when we started to shift out of our developer specific like customer, like when we started to think about, okay, well, there's this developer, but there's also.

 I don't know, like the finance person at a company who cares about Stripe. They're like the CFO, there are a lot of other people who care about sort of like the product that we're building and how do we actually serve them really well as well. And then also, honestly, as this, as the product gets more and more complicated, and there are a lot more moving pieces that you kind of need that organizational glue and somebody who can really understand, um, the end to end from an organizational perspective to drive it forward as well.

I think a lot of places, it is a question of composition, right? I think if you have an engineer, I think even as Stripe, like if you have, and engineer, who's really, really strong in this sense, like maybe it doesn't make sense or you don't need a product manager as well. And maybe there are some other places where actually does make a lot of sense from a team composition perspective, because you have people who spike in different areas.

 what have you chosen to do at cocoon? Kind of going zero to one in terms of this question of. Uh, product managers or not, or who owns product in those types of things in the early days. 

 Yeah, I think one of our foundational values actually is everybody works on product. And so it's not just people's whose names have product in them. It's not even really only even the classic like product design and engineering, um, trifecta, I think for us, the nature of our product, it's very, I guess what we're building is infrastructure and sort of like a product that is very technology driven, but at the same time, it's also a very empathetic, like educational product.

People are learning how to go on, leave for the first time. And so all of those touch points from, um, an employer onboarding for the first time and learning how. Um, help them craft like the right leave policy to somebody who's literally in our dashboard product, um, using the product to maybe a parent who really wants to get advice, um, from somebody on our team on like how they can navigate their leave in the best way.

I think those are all things that we consider our product. And so that's why one of our foundational values is everybody works on product because it's not specifically only the, I dunno, the product engineered design product that sits, that happens to sit that is our dashboard, but it's like every single touch point, whether it's from an operational perspective, whether it's like a customer success, what, or whether it's a, um, like support perspective as well.

And so I think that's like how we're really thinking about it and then expecting folks to really take ownership like end to end as well, no matter what their role is.

 from a culture or a systems level, how do you, and maybe we could explore it in the context of striper and cocoon. How do you create a culture or a system? That's not like Lord of the flies where everybody's kind of doing whatever they want. And there is that, that there's, you know, potentially lack of product direction or prioritization or the dynamic where you can kind of have too many cooks in the kitchen, like too many people with too many opinions. Full stack and what they're responsible for? 

 Yeah, I think some of it, I mean, a lot of it honestly starts with making sure that you have a north star, first of all. So kind of the scenario that you described where kind of everyone's going off in other directions, kind of like herding cats in a way, trying to make all the cats go in the same direction.

I think you really do need to set, and this probably needs to come from the founders or leadership or whatever. What is our north star for like X timeframe, whether it's like the next five years is this year or this quarter, depending on where you are, um, in sort of like the company journey or the company life cycle.

Um, so I think there is a north star, like what the end of the day, what is the thing that we're all aiming for and how are we going to make certain trade-offs right? Like, what is the decision making framework and what are the principles like, how, how are we going to build our product?

Or how do we think about product quality or what are we going to prioritize, for example, like what's important right now. I think those are things that you are really important to write down or at least articulate so that it propagates throughout the org or the team. I think there is like a second level there as well.

And so for example, one of our big pillars or whatever you want to call it, um, for one of this year is like, how are we going to actually scale like to 10 X of volume? Um, making sure that we're not. if you're in an operationally heavy company, for example, that you're not like scaling with people and you're scaling with actual technology.

And so that's like an example of sort of like a north star. So everybody's thinking like, okay, like scale of 10 X, like that's one of the main missions that we have. Um, I think the other portion of that is we kind of have this notion of like a DRI. So you kind of asked earlier about how do you make sure that there's not like death by a thousand cuts of like opinions or too many chefs, in the kitchen.

I think maybe the DRI concept came from apple, um, kinda stands for directly responsible individual. And so I think the notion here is we want everyone to sort of feel very bought in and have Anton ownership for like the company and for the product that we're building.

But that doesn't mean that like everybody is like a blocking decision-maker if that makes sense, because I do think to your point that comes very chaotic and kind of grinds a lot of things to a halt. So I think we have this concept of a DRI who is the ultimate person who is accountable in some sense of the impact or the outcome of whatever our goals or missions or whatever are, and it's their responsibility to make sure they're looping in the right stakeholders, making sure that people feel heard and actually making a decision and at the same time having the accountability for that as well.

Um, so I think that's something that is really important when we talk about like collaboration. Like I think at the end of the day, I think our culture is extremely collaborative, 

But I think you do need to layer that with some sense of like, okay, then who are the deer eyes and certain initiatives. And then what does that accountability look like to

being in the DRI seat does it just tend to be the most senior kind of generalist product oriented engineers? Or is it, is it some other system to decide who's going to own what 

 I think not necessarily. And I don't think it's even necessarily engineer specific or PM specific or designer specific at all. I think for us like deer, I, it's not like a, I guess it's a, it's a role, not a title and it is very fluid.

 Right? So somebody who is a DRI at one point may not be a Dera DRI the next time of depending on what the project specifically are. 

I think it does need to be someone Who is able to step back and think about the overall goals and the outcomes. Not someone who's necessarily, um, only in the weeds, but I don't think that translates to like, it needs to be a specific role or a specific seniority, when you think about. Building cocoon from scratch. How do you figure out what you want to do differently than Stripe? Uh, and what are the things that you want to take with you and do in a similar way?

 And I would imagine that it might be particularly tricky because you spend a majority of your career in kind of one system. And now you're going and building a new company that in some ways has similarities in terms of jobs to be done, infrastructure, et cetera, but in some ways entirely. 

 I think the things for us that when we started thinking about how we wanted to build goon from scratch, that were really important. I think the few foundational principles that we had is number one, that the thing that we've already talked about, sort of like very impact driven, like engineering's not a vacuum.

How do we kind of help folks maximize impact, um, with this like kind of end to end ownership. And I think a second is sort of like how we want to work together too. I think there, like maybe a while back there was kind of this whole thing about like, oh, make sure that you hire nice people. I think there's a really interesting, I thought about it a little bit. I don't know if you just want to hire nice people specifically. I think you want people who are kind, who are generous and open-minded, but you want people who aren't afraid to push back on something they don't think is quite right or kind of debate passionately for, for the thing that they believe in.

And I think a big part of this and what we say internally is, is really debating without ego. I think it's not about pride or defending something they could just because it was your idea or starting with a holy war or whatever. I think we all have the same goal, right? Just to see cocoon incredibly successful and to have the impact on the world that we want to have.

And so How do we get to this together? And so a lot of this is like, how do we build a culture where it's not, that people are afraid to step on other people's toes because they feel like that's not nice. I think we want. People to push back on things that they don't think it makes sense right.

At that stage. But the, at the same time, we very much want to have this culture of kind of like self-reflection, um, like blameless. Postmortems is something that we say pretty often as well, when something goes wrong, like how do you move forward? And so I think that's something that is interesting where it's sort of, it's not that I think maybe people sometimes shy away from conflict, and I'm not saying that we want to have conflict, but I think you want to have intellectual debate because that's where the best ideas come from.

 Are there other things that you've done at the culture or system level that you think cultivate that right. In, in that the kind of the perspective that you shared makes sense intellectually, but it also seems like one of those things that pragmatically might be a little bit trickier than one would imagine. 

 some of it honestly like modeling, um, like role modeling, for example, too. So like I'm someone where I feel like I will sometimes have a strong opinion, but then I'm extremely easily convinced by rational arguments. And I think that some of it is this sort of like role modeling from the founders or like the early team or whatever, making sure that that's actually true, right? Like what you say you do is actually true in practice. And so it's almost like the next time that's you have something that you have feel really strongly about kind of really examining it really closely to try to understand like, okay, what is my actual argument?

 And then maybe a trick that I had sometimes done before is trying to argue the other perspective, um, from your side as well, just to really understand, um, what the debate is like actually about right. And breaking it down to like, I the principles, for me, when I talk about.

Disagreeing or how do you disagree or what's the most useful way to debate? Sometimes I kind of figure that if, if everybody has the same goal, so if you, if you have malicious actors in the picture, I think everything kind of goes out the window.

But if everybody has the same goal, we want cocoon to be successful. If everybody has kind of like the same information in some way, like the same data that we're looking at the same, like understanding of the system, the same understanding of like the problems, et cetera, unless something is completely a subjective debate.

Like, oh, my favorite color is blue and your favorite color is green. So that's why we want it to be like the website color of button color or whatever. Even that I feel like can be made to be objective in terms of a debate with data. I feel like at the end of the day, you should be able to come to.

 the same decision, or maybe it's honestly a total judgment call, right. Because there's something that's like 50% likely to be true and somebody needs just to make a risk-based judgment call. And so I think that when we talk about debating or disagreeing and stuff like that, I think it's really trying to narrow it down to like, are we actually disagreeing on the thing that we're agreeing or disagreeing on?

 Maybe what we're disagreeing on is one of us is missing context or information. Right. Or we misunderstood what the goal was supposed to be. And so I kind of usually try to use that framework if I feel like I'm disagreeing with somebody. And I don't quite understand why I think a lot of this is just trying to come from a place of like, self-reflection okay.

Like, does my, does the thing that I believe actually makes sense and are we all on the same page? And also just like, assuming like best intent from, from other people too, and having that kind of like mutual trust, um, yeah. And mutual respect and, and high trust for another. so looping back to the start of our conversation. are there other things that separate a junior mid-level and senior engineer in your mind, maybe other than kind of product or problem orientation or ownership, orientation, maybe communication. Are there clear things that come to mind that stride in those levels? 

I think the main thing that comes to mind, which is maybe the summary of kind of all of those things are what we're actually trying to get. It is having that multiplicative effect on the team. I think there are people or engineers who are incredible individual contributors, right?

Who can build something really fast or like get deeply into a problem. But they're not a team they're in individual. And by the way, when I say team, I don't mean that in order to become more senior, you need to manage people or, or whatever, or do like organizational development.

But I think there are, there's like, there's a foundation that you can set and a way that you scale yourself that is multiplicative. Um, and some of that is how you communicate. How does that bring people along? How it, some of it is like impact us as well. But I think about if you're asking me, like, what is the like one word difference between sort of like folks that are.

I guess like more new or, um, more junior in their experience. And then folks who tend to be sort of like the people who become leaders. I think it's like really understanding the scaling effect, um, and multiple multiplicative effect that they have.

 So I think that this is a good time to explore sort of this path that, comes up for every engineer, which is, do you want to continue as an IC or do you want to be an engineering manager? And I tend to think that the inertia of our industry tends to tie, uh, growth and seniority to management.

And I think that obviously a lot of the best companies have created, a dual track opportunity for senior ICS or senior engineering managers. Um, but I'm curious, maybe you can talk about your own sort of thinking about that. Initial decision and, um, what you've learned about helping people figure out which path has right for them. 

 Hmm, I guess the first thing I'll say, which kind of is calling on what you were getting out with a dual track is it's not all or nothing. Um, you can swing back and forth. It's what I did. It's what I saw a lot of amazing engineers do. And sort of like, like you mentioned, we do have this kind of dual career track set where I'm most companies now and think it's relatively standard where you kind of don't have to go into management in order to advance the company or to have impact.

I think the most important thing here, at least in my experience is really to figure out what gives you energy. I'm a very roll up sleeves, like in the weeds kind of leader. And that's honestly where I get my energy. I love building and I love being like in the detail. I enjoy many parts of like mentorship and leadership as well.

And I think in the cases where I've been kind of like the larger or glitter, um, multiple times in my career, I feel like I've been able to do it, but I always find myself gravitating away from it. So I feel like it is kind of important to listen to that gut feeling. And I think it's important to differentiate between what kind of feels like a standard career aspiration and like altitude on the org chart versus what you actually really enjoy, like that kind of altitude on the org chart or place on the org.

It doesn't really matter as much as impact and impact for me. I kind of feel like comes when you're the happiest and most productive. And so an example of this sort of like if you're in a role that you think you're in love with because of the title or whatever it is, or the place and or how many reports or something like that, you can try to force yourself to do things that you don't like.

Um, but you probably won't be incredible at it, right? You're not going to have the like, shower epiphany because you were thinking about it. I found myself procrastinating on things that were honestly really important that I was supposed to be working on, but I just like, couldn't get myself super excited about doing them.

I, even though they were important for my role. And so that's not to say that any role is like 100% things that you love doing all the time, but I think it's really important to have that balance of the energy draining things and then the energy giving things. And I feel like when you have too many things that are energy draining, but you're in a role cause you think you should be in it.

Amber Feng is the co-founder and CTO of Cocoon, and was formerly an engineering leader at Stripe for eight years. She shares her advice for other engineers wrestling with whether to take the founder, IC or management career track, and the engineering lessons from Stripe she’s bringing to her new startup. 

IC? Manager? Technical Founder? How to chart your engineering career path

After 8 years as an engineering leader at Stripe and now as a first-time founder, Cocoon's Amber Feng shares advice for other engineers wrestling with their career path.