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

Brett Berson: Amber, thanks so much for joining us. 

Amber Feng: Yeah. Really excited to be here.

Brett Berson: 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.

Amber Feng: 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.

Brett Berson: 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. 

Amber Feng: 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

Brett Berson: 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. 

Amber Feng: 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.

Amber Feng: 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? 

Amber Feng: 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?

Brett Berson: 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? 

Amber Feng: 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.

Brett Berson: 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.

Amber Feng: 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?

Brett Berson: 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.

help people behave in this. 

Amber Feng: 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.

Amber Feng: 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.

Brett Berson: 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.

Amber Feng: 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.

Amber Feng: 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. 

Amber Feng: 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? 

Amber Feng: 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

Brett Berson: And when you think about who ends up.

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.

Amber Feng: 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?

Brett Berson: 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. 

Amber Feng: 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.

Brett Berson: 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?

Amber Feng: 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?

Amber Feng: 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.

Brett Berson: 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. 

Amber Feng: 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.

That's when kind of things get a little bit out of whack. And I feel like you just start to not usually you just don't have the impact that you want. Right.

 when you think about what are the component parts of being an excellent engineering manager, what are they in your mind? 

Amber Feng: there are a couple of different parts. I think one is, um, and maybe this is controversial. I do think it's important for managers to be functionally excellent in their roles. Um, and so sometimes it might be trying to find a Euchre of somebody who is functionally excellent or, and really, really wants to do that sort of like career development and learning.

But the reason why I think it's like important to be, um, functionally excellent or have this sort of like, end-to-end kind of like ownership that we were talking about before, which kind of builds into that excellence is because at the end of the day, I feel like. Managers, do you need to be accountable or responsible for the outcomes, um, or impact of their team?

I think the second part of it is, and maybe these things are sort of like interrelated. I think for managers, I think it's really important for them to kind of embody, um, the best of the values that you want to propagate. You have somebody who is in a leadership role, who is mentoring and coaching other people.

And so like you want to, you want to make sure that the value is of the principles that this person has are things that you truly want to propagate throughout the org because they will, whether you want them to or not. And so I think the second part is sort of like, do they embody sort of like the best of the values or principles, um, of your team that you want to actually continue to grow?

I think this third part too is sort of, and this is when it gets really into the deeper sort of like career development, like coaching, like mentoring. Um, I think that's something that was really interesting to me that, um, Claire Johnson, who was the, COO at Stripe had said previously that.

We wanted to strive to be the kind of place where people had career defining highlights, and that kind of phrase has just always bounced around in my head, like career defining highlights. Like, yes, like when I look back at my time at Stripe, that's in a sense where I grew up, right. Or I learned almost everything that I know, and that I would definitely say is like one of the highlights of my careers.

And so when I think about cocoon, something that really resonates with myself really strong or really resonates with me really strongly. And I, I want to make sure that we have is that people, whatever they end up doing later, co look back at cocoon and we're like, damn, that was like a career defining highlight for me to be at that company to be in the role I was at.

I learned so much like, and stuff like that. And so I think the third critical piece of a manager is how do you. And as an essence, give people that, right. How do you make sure that their time on your team at the company, whatever is something they look back on and they thought it was, uh, it was career defining.

So maybe it was like, they, you were able to coach them and unlock certain skills that they wouldn't have been able to do earlier is maybe it's like you change their mindset around how they approach their job. Um, maybe you like advocated and made sure they had the opportunities to be challenged, to sort of grow an enormous amount.

 when you think about those kind of three component parts, how do you think that might ladder to maybe the set of questions that an engineer should be asking if they want to go down or this direction is right for them. So maybe they're five to seven years into their engineering career.

Brett Berson: And they're kind of at this fork in this road And they're thinking about, is this for me? What do you think the things they should be thinking about are. 

 well, I think one of them has the energy questions. So one of the most important things about being a manager or any leader in that respect is your impact is no longer just your own impact. It's the impact of your team. Right? And so when you're thinking about that multiplicative effect, whether you're a manager or whether you're sort of like a technical leader that doesn't manage people, I think that is really important.

Amber Feng: Like, is that something. That like you're excited to work on, right. When you're a manager, a lot of that is having the impact for people on your team. If you're someone who gets the most amount of energy by coding, uh, or like by building systems or by even by building some systems that are foundational to like the company, you may not enjoy having this sort of like indirect relationship with sort of like those problems anymore.

Right. Maybe you will though. It's sort of like add a different, um, I think it's at a different level and it just like is a little bit more indirect. So I think that's the first thing I would say is like, what are the things that give you energy kind of like, look at that in your day to day, try to figure out how that would be different.

Like, is that going to make you happy? Are you going to be excited? Are you gonna be having shower thoughts, write about those kinds of problems and challenges? I think the other ones kind of like translate, um, as well. So like the functioning excellent end to end ownership like that stuff is all.

 I think that engineers should be working on regardless the value one as well. Um, whether you're a leader called that is named a manager or a leader that is not a manager, I think it is really important. Um, to kind of be careful about the values that you are propagating throughout the team or the org.

Amber Feng: I think the last one is probably the kind of career development, like what, um, type of feedback that makes you happy when you're a direct engineer and you're hands on keyboard, coding, something, you're building something.

I think that feedback loops can be very fast. Right? Um, you're, you're finding, like you're seeing what the impact is almost immediately. I think, as a manager, I think the impact that we're talking about when we talk about how. Career defining highlights. That's not a like going to find out like next week I like wrote the test or we got the user feedback about whether it worked or not.

I think that's like, um, months, potentially months or maybe years to see if you had the kind of impact, um, that you wanted. And so I think that's maybe something that I would think about too, which is like, is that something that is going to feel satisfying? Like I personally find it fulfilling, but I think people like different modes of working and like different types of, um, work styles in that way.

Brett Berson: When you think back to when you first transitioned into an engineering manager role, were there a S like a clear set of mistakes or errors that you made, that you kind of figured out your way through and maybe what were they, or what did you learn or what did you figure out that, that has served you since then? 

Amber Feng: Yeah. So, so many things where to begin. Um, I think the biggest learning I can think of, um, that does kind of sound obvious in retrospect, as maybe most things are, is kind of just always being really brutally honest with yourself and your team. I think one very vivid example of this is I think, early on for me, um, I think I had like a somewhat misguided sense of being overly protective of my teams.

I had this like notion in my head. Okay, well, again, manager's job is to be like extremely supportive, like no matter what. And I think while I think that's true, I think I kind of twisted that in a way where I was over shielding or being overly optimistic or positive, even when something goes, it wasn't going well.

So it was kind of like doing everyone a disservice. So like, yeah, maybe the very vivid example in my head, um, that I always remember is that on one of my really early teams at Stripe, we were working on a big project to rewrite our entire dashboard. Uh, this is the type of classic project that is basically destined to fail because you're chasing a moving target.

Um, and I think it definitely also didn't feel good in the moment. It probably, honestly, if I look back felt like a big elephant in the room where nobody was like really sure whether it was going well, but I felt the need to like, stay really positive and upbeat and encouraging about the whole project.

And I do think a lot of maybe first-time managers are very well-intentioned in this way. Right. They want to be supportive. They want to make sure people are happy. Right. that's what they think is like their mandate. And as you can kind of imagine, I think it ended up in the worst way possible.

We basically decided that the project was not working. We abruptly canceled it after about a year of kind of continuing to sink time into a project that just wasn't close to shipping. And I think in retrospect for me, we should have been having way more conversations about the fact that it wasn't going well.

Like the risks, like how to de-risk even if that felt like demotivating to the, the team in the interim. Um, or maybe it wouldn't honestly, it probably wouldn't have been demotivating because I think people rally around problems. Right. And I think I was trying to overly shield people cause I was like, well, it's my job to make sure people feel supported.

Right. And I think that was just like, it was support in the wrong way. And so, like I said before, I think maybe all of that seems really obvious in retrospect, but I think there were even some ways today where I find myself again in a very well-intentioned way. And I think that we all do this. Just try to downplay some like maybe uncomfortable truths.

Um, and I kind of have to remind myself that having a no surprises culture where they're just like no elephants in the room, like feels way better.

Brett Berson: Are there ways that you keep yourself accountable to behaving in that way? 

Amber Feng: I think some of it is remembering what, uh, the, the failure mode of that project. I don't think I've done it. I definitely have not done it quite to that extent before I think some of it. Okay. I think one of the areas, and maybe this is more related to giving feedback. I think in some ways I feel like tech sometimes gets feedback a little bit wrong where.

I think what usually happens if you're a hype, like a strong performer, um, at a company is the feedback that you'll end up getting is like, you're doing great. Right. Uh, and that's like the extent of the feedback cause you're doing well or there's nothing else. And I think that's like probably like, well, maybe helpful in the moment or makes you feel good that you're, you're doing great.

I don't think it's actually helpful in long-term and kind of doesn't have maybe, maybe it's not an elephant in the room, but it doesn't help people actually improve in like a brutally honest way. Whereas if you think about how sports, I mean, maybe this is top of mind for me because the Olympics were just happening.

I think the approach, if you think about the way that sports, uh, purchase coaches and feedback, right. If I was like a Olympic gymnast or like an NBA basketball player, and I asked my coach like how I was doing, and they're like, you're doing great. I'd be like, what the heck you're fired? You're like the entire, the entire point is you're supposed to be giving you brutally honest feedback.

Like tell me exactly what I'm doing wrong. Right. So I kind of feel like for me, some of it is. Revisiting what feedback means, um, and thinking about that kind of like, yeah, like we want to be a Olympic athletes. We want to be world-class in what we do and what we kind of need is kind of the brutally honest feedback.

Not because somebody is trying to like, be mean to us or whatever, put us down, like actually the opposite. The only reason I would give brutally honest feedback to somebody in my team is because I actually wanted them to improve because I spend a lot of time thinking about what that feedback should be.

I spend a lot of time paying attention and then trying to craft that feedback for them. And so some of it is sort of reshaping how I think about feedback too, for myself and for people on my team. And then I guess I always maybe have this timer in my head of, if I feel uncomfortable at something it's like, okay, is this something I should actually be talking to my team about rather than.

Trying to like solve it myself. And like, is there any kind of elephant in the room that we just need to talk about immediately so that the team feels really bought in and there's a chance for people to kind of like rally around the problem and step up to the challenge.

Brett Berson: Do you think that the root of that problem, which I think is so great to highlight is you just want to be complimentary to people that are doing great, or is there some part that it's just, it's harder to really figure out what the gaps are for a star performer? Where if you think about the bottom third of people you work with, it's just easier.

You can just identify the glaring problems or the things that they need to work on. 

Amber Feng: I think people have an idea and they're probably not saying it. So I agree that for people who are not doing well for Australians, it's really easy to think about the like specific tactical things that they should, they should be doing better. Right. I do think even for sort of like the folks who are doing the best, maybe it's not like a tactical thing that you need to improve on, but it is something more fundamental to how they work.

 And some of it is actually just understanding what their goals are. Right. And so if I had a star person on my team and they told me they wanted to be a founder, all of a sudden I have so many ideas for things that.

Amber Feng: I think they could be doing more of that. They should be learning of like blind spots for them, et cetera, because I know they want to be a founder. And that doesn't mean that they're a bad engineer, right. There's not there's doesn't mean I have like a lot of feedback tactically about what they need to improve on for their code quality.

But I think it's sort of maybe shifting from, for people who are doing really well. I think it's shifting from thinking about like critical feedback or constructive feedback. I think that can be hard to think of and more of like, okay, well, what is this? What's the next level of what this person should be because they're doing so well.

So maybe they're an incredible engineer and I want them to lead one of our big business lines in the future. Like, okay, then what are the gaps there specifically and how we can, how can we actually work, work through them?

Brett Berson: One of the things that you mentioned earlier that I thought was pretty interesting was this kind of bouncing back and forth between different roles in the eight plus years that you were at Stripe. And I think that like kind of the normal orientation is you're an engineer. You know, you decide that you want to be an engineering manager at some point.

You have that capability or you're wired in that way. and then you kind of slowly, okay. you're an engineering manager with a small team. Then you're a senior engineering manager, director VP, and you kind of go on this

multi-year journey and it sounds like you did something quite different and I'd be interested to learn more about like what, what you actually did and how you made that work for you. 

Amber Feng: Yeah. So I think definitely swung back and forth, uh, between a couple of different roles. So, um, when I first joined Stripe, um, I was a bright eyed, bushy tailed, new grad, uh, working on, I guess at the time it was just literally our team or like our product team or something like that. There weren't any real teams.

Um, And I think I kind of found myself in a position where a couple years, and I was leading our product engineering organization. And so that grew to 2030 people. Then maybe this is what you're alluding to, uh, or potentially in, in other organizations or indeed in an alternate universe, I could have stayed with that and sort of like climbed the ladder of the organization.

I think I actually flipped to, uh, Uh, team, I like kicked off a team called treasury, um, which is basically a team responsible for all of, for tracking all of Stripe's money movement, which is very critical to the company. But I basically flipped over to like start this team from scratch. Um, then a couple of years passed and that team kind of, um, grew to be around like a hun a hundred engineers.

And then I kind of did the same thing then I was like, Hmm. Okay. Um, and I flipped over again to actually start from the ground up a second small team, um, the ended up building stripes, corporate card and banking products.

Brett Berson: Was there something about the way in which Stripe was organized that allowed for this to happen in such an effective way for you? 

 I think it's striped. There was always a lot of openness, um, around mobility. And so, like, I think there there's a lot of encouragement around, around like cross-pollination of knowledge, like moving teams. Um, and I think later on they had actually formalized some set of those where folks can move teams that they want for me, I think.

Amber Feng: And maybe this comes back to sort of like the energy thing that I was talking about earlier. I think I just knew that where I got energy was sort of like more of that on the ground building rather than being sort of like the large organizational leader. Um, not that there's anything wrong with that. I think it's just like, it's not where I personally found myself like extremely excited every day.

And so maybe for me, it's sort of a combination of like, um, feeling really strongly that I would do my best. Doing whatever I was actually most excited about. And then also being really intentional and intentional about what I wanted to learn. Kind of like I was saying earlier, the like wanting to be on the steepest learning curve possible.

So like that's what kind of inspired me to kind of drop back down to do something different and it totally different domain. So like moving from like building product and API APIs to financial infrastructure and then moving from engineering to being a business lead of a totally new business area. But I do think there was a lot of support overall for that.

Brett Berson: So going back to this idea of a steep trajectory or high degree of difficulty, I'd be interested to learn a little bit about what what's your experience been starting a company from scratch as a co-founder and CTO. Um, and, and maybe what's not been surprising. And what has been surprising thus far?

Amber Feng: Um, I think I knew that it wasn't just going to be about the engineering. So obviously in the beginning, like in the first period of time, or you're building the product, you're figuring out what, what needs to exist. And then the part that I was really excited about was a lot of the company building, building the right team, um, figuring out what our culture should be, what our operating principles, frameworks, et cetera, like not just building a product or a system or, but building a company just because I had experienced a lot of that early Stripe.

Um, I think what surprised me is how fast that happened. Uh, and maybe, I mean, this is in some ways the best possible problem to have. I think for cocoon specifically, I think it just accelerated incredibly quickly. I think we found our product market fit incredibly quickly and then very quickly was I kind of booted out of sort of like my most leveraged impact being engineering.

Brett Berson: And instead the. Important thing I should be doing is actually building this team and honestly recruiting. So I think maybe not surprising cause I kind of had an inkling that's what I would end up doing. Um, but I think it was extremely surprising how fast it happened.Similar to what we were talking. Earlier in terms of some of the things someone should think about if they potentially want to transition into an engineering management role, you have thoughts on, on things people should think about if they want to be a co-founder and CTO, or maybe advice that you give, when folks maybe that you worked with in the past, or thinking about starting something and figuring out if it's for them. 

Amber Feng: I think there are a few things that are table stakes, so excited about the thing that you're working on or excited about the mission. Are you willing to kind of have that level of commitment? Um, I think those are maybe harder to talk about because they're so varied in what they are is like, it depends on what you're interested in.

It depends on what your like life situation is and whatever. I think that maybe the two things that I would say that are a little bit more tactical are number one for me. I think at the end of the day it was whatever. Finding something I was excited about having the commitment, but also making sure I kind of had the right team.

And what I mean by that is finding the right co-founders that are complimentary, um, not just in skillset, by the way, but also in terms of this kind of thing I was saying about giving and draining energy. I think that, especially as an engineering, co-founder I think there are a lot of things that I know are my kind of super power.

So I know my super power is in execution. I know that I'm definitely weaker at the equivalent sort of like go to market distribution, higher level strategy that I think a lot of engineers just don't have as much, um, experience or exposure to. But I think from the energy perspective, I also know that I like being internal facing not necessarily external facing and I like being really deep into problems.

Um, and so I think maybe the question is sort of like. Are you going to be able to actually assemble the right founding team? I think that does take a lot of the stress out of founding a company. I definitely would not have done it myself or without the people that I thought were really complimentary. I think maybe on a related side.

I think the other thing that is extremely important, uh, is making sure that you share the same values. Um, so what we actually did, so me and Mahima and Lauren, um, I'd worked with Lauren before, but had never worked in the Hema. We went through the, uh, co-founder dating questionnaire, uh, which I know, uh, was also published on first round by Gloria to really test yourself on some of these sort of like heart disagreements.

And I think that's actually really helpful because it gives you a little bit of a preview without kind of jumping into it yet. Like what would actually be to work together, what it would actually be like to work together and to actually disagree on something. So some of the questions that it goes over are like, how should you split equity?

Like, do you want to get acquired? Or do you want to IPO? Like how much money do you want to raise? Like, cause I think that you do have to, you do need to get that stuff out of the way. And you do not want to realize that you are totally philosophically aligned on values while you're building the company.

And so I think maybe those are like two of the tactical things. Cause I think for me it really was about the team. And I think that a lot that plays a lot of that plays a lot into what it feels like day to day

Brett Berson: And did you find that now that you've been building and probably getting into situations where you can actually see how people's values are expressed, that that exercise was a reasonable simulation for what's been happening in the real world? 

Amber Feng: Oh yeah, totally. Um, I think that. Because I think he'll never going to be an efficient, you'll never be in a situation. And actually you never want to be in a situation where you'd never disagree on anything. Like what does that even mean? I think people, it is good to have like healthy debates about different perspectives.

Right. And I think that just like makes us stronger as a team. I think the test was like, can we disagree in a way that felt productive, right. Are people willing and are people on Crump compromising or is it really hard for me to understand rationally why somebody is kind of sticking to a, a stance that they have?

And so I think that over the course of building cocoon, like we've disagreed a ton, we've resolved as disagreements. There are areas where it's been really stressful. And I think the thing that was really important for me to get out of that initial dating period, um, was like, are these people that I can trust to kind of have my back and to be like high integrity, um, To be, to have like high ethics and that I'm going to really enjoy kind of being in some like, really stressful situations with right.

Brett Berson: Something that I think is kind of interesting about your own journey is that the first formative part of your career was over eight years at Stripe. And now you're, you're building something from scratch. And I assume you aspire to have lots of folks that choose, um, to make cocoon their home for eight plus years.

 what is it about you and what is it about Stripe that created the dynamic where you would spend such a long period of your career at one place? And how does that translate into some of the things you're thinking about as it relates to who you recruit or how you behave as a company to maybe increase the odds that you can create those opportunities, uh, for someone that cocoon. 

Amber Feng: yeah, I think the maybe cop out, none of it's caught bell. I think the, maybe the answer to why or one of the answers to why I spent such a long time at Stripe. Honestly that it was really easy to the job kept changing. I don't mean easy as in a comfort zone thing. I think for me, I was really craving and thriving in a high level of steep learning curve.

And I think that Stripe, the way the company was doing, um, was growing was the job literally kept changing. Right. I worked on different, really interesting problems. I found myself learns. I learned so much and grew so much myself, made a ton of mistakes. Um, it is a place where I look back and I'm like, kind of when I was saying about the like, career defining highlights, right.

I think that there were just too much that I was learning at Stripe such at the opportunity costs didn't make sense to ever go anywhere else. And I think it is about sort of like that framework of like what you're optimizing for. So for me, it's sort of like that learning angle, like, am I learning more doing what I'm currently doing than I would somewhere else?

I still felt like I was learning more than I would. Um, even starting my own company, given how fast the company was moving, I feel like I was at like eight different companies. Right. Um, at different stages of, of Stripe. And so I would say like, figure out what you're optimizing for. And for me, it's like figuring out what people on my team are optimizing for and hire people who are optimizing for that learning and impact, because that aligns with sort of like what I think I want to be mentoring people in.

And I think the second thing is career paths. I think early stage are very organic. Um, I think a lot of it is kind of, well, a lot of people, I think what people say is a lot of it is right time, right place. Right. I think it's right. Time, right place. And that's more about the company, but I think the thing that is about the people or the person is that it also requires the right focus to, and so you might get the right time, right.

Place for free, but are you actually focused on the right thing? Are you actually having that impact that matters. That's what I actually spent. A lot of my time working with people on is making sure they have the right focus so that when the right time and right place comes along, they're sort of like able to take full advantage of it.

And I think that if you are high trajectory at a company, um, and this is what I'm thinking about for folks on I cocoon as well, we'll want to put you in sort of like positions of more and more impact and also keep people there.

And I think that the type of people that we are hiring are people who care about the impact, who care about the learning. Um, and so I think that really helps keep people for a long time. And I think it's my responsibility to make sure that is where people are growing as well.

Brett Berson: I think that's a cool place to end. Thank you so much for spending this time with us. This was awesome.