How to Chart Your Engineering Career Path: IC, Manager or Technical Founder?

How to Chart Your Engineering Career Path: IC, Manager or Technical Founder?

From early employee to technical founder: Amber Feng shares essential lessons for engineers up and down the org chart, drawing from her 8-year career at Stripe and becoming a technical founder of Cocoon.

There are numerous forks in the road along an engineer’s career path. Do you want to stay an IC, diving deep into the codebase and shipping new features? Do you set your sights on management, climbing the ranks and eventually leading a large org? Do you stay on board as a small startup hits scale and gets bigger and more complex, or does the pull of building from scratch draw you back to an early-stage environment? And finally, do you have an eye for entrepreneurship, with your own goals to become a founder?

Over the course of her eight-year stint at Stripe, Amber Feng faced each of these questions.

As a new grad, she was one of the famed startup’s first dozen hires and climbed its ranks from scrappy IC, to first-time engineering manager, to starting her own teams from the ground up and directing hundreds of folks under her orgs.

It’s quite atypical for engineers to spend eight years at a single company — particularly with countless job opportunities piling up in their inbox. So plenty of folks quiz Feng on why she bucked the trend and stayed put for so long. “With Stripe’s trajectory, the job was changing all the time. Over the course of my eight years there, it felt like eight different companies. Too often folks hop to the next company opportunity prematurely, leaving a ton of untapped learning potential at their current company and role,” she says.

When Feng eventually did start to feel the pull to leave, it was to forge her own path. She teamed up with Mahima Chawla and Lauren Dai (a fellow Stripe alum) to found Cocoon — an employee leave management platform (of which First Round is a proud seed supporter).

In this exclusive interview, she guides other engineers up and down the org chart as they weigh their next career moves, leaning on the frameworks and lessons she’s pulled from in her own career. First, she uncovers a few under-the-radar traits that set the most impactful engineers apart from the pack. Next, for folks weighing the decision to move into management, she gets real about the four pieces of advice she wished she knew when she first became an EM. Finally, she turns her attention to the past couple of years building Cocoon as a first-time founder — particularly the elements of Stripe’s operating principles that she's weaving into Cocoon’s cultural fabric. Let’s dive in.


“When people talk about great engineers, there’s a lot of emphasis on writing code, designing systems and building products. All of that is extremely important. But I see lots of folks who are drawn to engineering for engineering’s sake. They’re hyper-focused on the type of system they want to build, regardless of whether it actually solves a problem, to the detriment of their long-term growth,” says Feng.

The best engineers I’ve worked with aren’t necessarily the ones who write the most complex architecture, they’re the ones who can think through a problem really deeply and are endlessly curious.

She sketches out a few traits that tie together the standout engineers she’s worked with over the course of her career.

They’re crisp writers and communicators.

At Stripe, the company enforced a strong writing culture, which Feng has since brought along as co-founder of Cocoon. But in the early days, it wasn’t a skill that came as naturally to Feng. To shore up her own writing skills, she kept a close eye on the strongest folks at Stripe and noticed a few key areas that the best communicators had in common.

  • Concise. “People often think being a strong writer is about using flowery language. But one of the biggest steps is actually figuring out how to be concise. How can you convey the most important information, like updates, blockers, highlights, risks, etc. with just a short summary?”
  • Tailored. “It’s about learning how to read the room and understanding your audience. Whether it’s talking to non-technical folks or talking to customers, you need to be able to put on different hats and adjust your communication accordingly. What’s the essence of what this audience needs to know?”
  • Anticipate and address the FAQs. “Whether you’re writing a doc, an email or an announcement, you’ve got to anticipate what questions might come up. You can even ask folks around you what their own questions are about your project. When you force people to go through that thought exercise, they start to put themselves in the shoes of whoever is reading the email or the customer update.”

Feng also flags another underrated aspect of great communication that deserves your attention. “I’ve found that at the heart of great writing is bringing others along and helping them understand the decisions that you’ve made. If you’re part of an early team, sure you’ve built the foundation of the codebase and the architecture. But, more importantly, you’ve built the culture and the quality bar and the decision-making frameworks, and these need to be captured in writing so they can live on across the org,” says Feng.

Great communication is about more than just saying what you’re trying to accomplish. It’s about helping folks understand how you make decisions so they can be able to make similar types of choices in the future.

They aim for the broadest impact.

“When we talk about engineers, too often we hyper-focus only on whether you can ship code quickly or design the most scalable or robust system. But the more important question is whether you can drive actual impact at the company,” says Feng. “As a founder now, I often say that I’m hiring entrepreneurial generalists — people who think deeply about the problem they’re solving, not just from a technical perspective — maybe it’s an organizational problem to solve. They constantly question whether they are even building the right thing.”

Her advice for engineers who hope to take on an ownership mentality? Try to get in the room where it happens. “It’s really important to be able to see other people drive projects end-to-end and examine what made them especially sharp. Think about how you can get yourself in the right roles or companies where you feel like you’re learning on the ground,” says Feng.

And there’s no replacement for getting as close to the customer as possible. “You can hear anecdotally from user research or look at a product brief that explains the problem, but there is no substitute for jumping on sales calls and listening to what customers have to say,” says Feng.

Engineering doesn’t operate in a vacuum. Who are you actually building for? Reduce the feedback loop as much as possible. Literally, go find your user, sit next to them and see what they’re doing. Become steeped in the problem.

“Watch them use the product, see what buttons they’re clicking and which ones they’re not. What are they confused about? What flows do they use?” she says. At Stripe, the company reinforced this habit from the beginning by adding engineers to the support rotation, with engineers getting paged if a customer question hadn’t gotten a response.

“Being able to chat synchronously also helps. Email is slow – add them on Slack, IRC, Discord, text message, whatever makes sense for your company,” says Feng. And as much as possible, try out the actual product from a user’s POV. “Dogfood your own product to understand what the problem is, not just what the feature requests are. You’re not trying to build a faster horse, you’re building the car.”

Amber Feng, co-founder and CTO of Cocoon


Before becoming a founder, Feng spent eight years at Stripe — but plotting the points on her time with the company, you wouldn’t see a traditional pattern. Rather than climb a traditional ladder, she’s gone from IC, to manager, to exec, back to IC many times over. Drawing from that well of experience, she doles out four lessons for first-time EMs.

Know you can get off the track.

“When I first joined Stripe, I was a bright-eyed and bushy-tailed new grad. At the time Stripe was just about ten employees and there weren’t any real teams. But a couple of years later, I was leading our product engineering org that had grown to 30 people. In an alternate universe, I could have continued climbing that ladder,” she says.

Instead, she took an alternative path. “I kicked off a team called Treasury, which was basically responsible for tracking all of Stripe’s money movement. After starting that from scratch, a couple of years later that team had grown to 100 engineers,” she says. Once again, she went back to building 0 to 1 within Stripe, starting a small team that built Stripe’s corporate card and banking products.

So her advice to other engineers who are weighing whether to stay an IC and build or to go the management route is that the paths can overlap. “You can swing back and forth — it’s what I did, and it’s what I’ve seen a lot of amazing engineers do. Listen to that gut feeling. If you’re in a role you think you’re in love with because of the title or how many reports you have, you probably won’t be incredible at it,” says Feng. “That’s not to say that any role will be 100% things you love doing all the time, but it’s important to balance the energy-draining things with the energy-giving things.”

When it comes to career aspirations, it’s important to differentiate your altitude on the org chart from what you actually enjoy doing day-to-day.

“One of the most important things to remember about being a manager is that your impact is no longer just your own — it’s the team that you’re managing. If you’re someone who gets a lot of energy from coding or building systems, you may not enjoy having an indirect relationship to those problems anymore,” she says.

Encourage, but don’t shield.

“The biggest lesson for me is the importance of being brutally honest with yourself and your team. I had a misguided sense that it was the manager’s job to be overly optimistic or positive, even when something wasn’t going well,” says Feng.

“Early on at Stripe, we were working on a big project to rewrite a huge part of our product. It was one of those classic projects that was destined to fail because you’re chasing a moving target. If I look back, it didn’t feel good in the moment and folks in the room knew it wasn’t going well. But I felt the need to stay really upbeat and encouraging,” she says. “As you can imagine, it ended in the worst way possible. We abruptly killed the project after a year of sinking precious time into it.”

Many well-intentioned, first-time managers think their job is to sidestep uncomfortable truths.

“In retrospect, I should have been having way more conversations about the fact that it wasn’t going well. I think a lot of first-time managers are well-intentioned in this way. They want to be supportive. They want to make sure people are happy. They think that honestly talking about the risks will be demotivating. But it’s often the opposite — people want to rally around problems,” says Feng.

Here’s how she’s tactically made that shift. “Ask a peer or a friend to keep you honest. Every week, have them ask you three extremely direct, uncomfortable questions about your project. ‘Why is the project delayed? How do you know whether the team achieved the right outcome? Is a person on your team underperforming?’” says Feng. “In the hectic day-to-day, it’s easy to justify slippery timelines or let these important questions slide to the backburner. You need someone to pull you out and who you trust to keep you accountable.”

“If you have a spidey gut sense, acknowledge it. Are you feeling nervous about a project? Why? What’s wrong with it? Others probably have that sense too and it’ll feel much better to be able to talk about it and problem-solve together,” she says.

Next, create a safe space for the team to share their own concerns. “At Stripe, we often reflected on one question: If Stripe failed at the end of the year, what was the most likely culprit?’ Do a hypothetical exercise with your team of projecting outward — if your project or team failed, what was the most likely reason? Invite your team to share their FUD (fear, uncertainty, doubts) in a safe space. You’d be surprised what critical context or ideas folks offer up in these honest moments,” says Feng.

Give feedback like an Olympic coach.

Feng also points to a sneaky undertow when it comes to feedback in tech. “When you’re a high performer, the extent of the feedback you receive is, ‘You’re doing great!’ And while that makes you feel good in the moment, it’s not actually helpful in the long term,” she says.

I think about if I was an Olympic gymnast or an NBA basketball player and I asked my coach how I was doing. If all they told me was, ‘You’re doing great!’ I’d probably fire them. Your entire job as an elite coach is to give brutally honest feedback. I want to be world-class at what I do, so I want you to tell me what I can do to improve, even incrementally.”

We want to be world-class Olympic athletes in what we do — and we need brutally honest feedback to get there.

When it comes to doling out impactful feedback for high performers, Feng recommends starting with the report’s career goals. If you don’t know what people on your team care to learn about, you’ll struggle to give them useful feedback unless they’re actively underperforming. “If I have a star engineer on my team who wants to become a founder, all of a sudden I have so many ideas for them. The feedback probably won’t only be about improving their code quality. The feedback will be about what they can do to take on more leadership with one of our big business lines, to get them closer to their ultimate goal,” she says.

Operate with scale in mind.

“When you’re an IC and you’re hands-on-keyboard coding, the feedback loops are typically quite fast. You’re seeing the impact almost immediately. But as a manager, there’s a mindset shift,” says Feng. “When I say I’m a roll-up-my-sleeves kind of leader, I don’t mean that I’m trying to get involved in every single thing that happens. I mean that I like to deeply understand the things that are happening and try to provide thoughtful advice or frameworks, so that when someone comes to me with a thorny problem, we can have a meaningful discussion.”

She’s instituted a new ritual to put that philosophy into practice. “My new rule for myself is that when someone asks me a question or asks me to make a judgment call, I try to write out my thought process, rather than just a direct answer. I want my team to understand how I came to that decision so they can make those calls in the future for themselves,” she says.

Advice for future founders.

For engineers with ambitions to become a technical founder someday, Feng reflects on her own transition — returning back to what gave her energy. “The part that I was really excited about was all of the different pieces of company building: assembling the right team, figuring out what our culture and operating principles should be — not just building a product or a system,” she says.

And although she did plenty of 0 to 1 building at Stripe, adjusting to the stakes as a founder was a steeper incline. “If you’re part of a bigger company working on a product, you have a lot more resources to lean on. You can cry for help and get more support. But as a founder of your own company, the buck really stops with you. You have investors or peer founders to lean on, but you do have to get comfortable with that existential shift,” she says.

For folks weighing whether or not they’d like to jump on a founder opportunity, she sketches out a few must-haves:

  • Mission. “You have to be incredibly excited about the mission — not just the product you’re building. Are you committed to tackling the problem? In the early days, the product can change so much. You don’t want to get too caught up in excitement about a particular solution or technical challenge.”
  • Team. “Find the right co-founders who are complementary to you. My superpower is in execution, whereas I’m weaker in the higher-level future vision setting. I care about being internally facing rather than an external spokesperson. It was important that I found co-founders who balanced these with their own strengths.”
  • Forecast. “My co-founders Mahima, Lauren and I went through the Co-Founder Dating Questionnaire, which gives you a preview of what it would actually be like to work together. I highly recommend any potential founding team go through these questions. Some cover how you’d split equity or if you want to IPO versus get acquired. Other questions are more philosophical around values alignment. You don’t have to agree on everything — in fact, it’s probably better that you don’t. You want to see how folks can engage in healthy debates about different perspectives.”


Although Stripe changed drastically in the eight years since Feng had joined the company, the reality she was facing when co-founding Cocoon was that she had really only been exposed to one company culture. Her task, like any first-time founder, was to pluck out and borrow the bits that she wanted to weave into her new company’s cultural fabric. She explains the ways in which Stripe’s culture has influenced Cocoon’s — along with one other tactic the company borrowed from Apple.

Honing product instincts across the org — not just the product team.

Stripe notoriously took the unconventional route in the early days of not having any product managers. “The thinking early on was that we were engineers building an API for other engineers. We wanted the feedback loop to be as fast as possible. We would be g-chatting our users (before Slack existed) asking what they thought of the product — getting digitally as close to our customers as possible,” she says.

But once the company began to expand beyond the exclusive developer audience, Stripe brought on more product folks. “As the product gets more complicated and there are a lot more moving pieces, you need that organizational glue from someone with an end-to-end perspective,” says Feng.

While early on this approach certainly worked out for Stripe, too often, Feng sees this lesson that you don’t need product managers applied too broadly across the tech scene. “Stripe had a really strong foundation of engineers with stellar product instincts. It’s less about whether you have specific people with the product manager title, and more about looking at the skill-sets at the company. Are there people who happen to be engineers or founders that are doing the job of a product manager already?”

While Cocoon has product folks as part of the early team makeup, diverging from the Stripe model, Feng and her founding team have layered on that product lens across the org. “One of our foundational values is that everyone works on product — not just people whose titles have the word ‘product’ in them,” she says.

This goes beyond the typical engineering, product and design trifecta. “We’re building an infrastructure product that’s very technically driven, but at the same time, it’s an educational product. People are learning about how to go on leave for the first time. All of those touchpoints, from onboarding to helping companies craft the right leave policy to giving advice to a first-time parent, are all about the product,” she says.

Appoint a conductor.

But every person at the company weighing in on product decisions would lead to a chaotic symphony of voices without a conductor. “First, the founders need to set a North Star that clearly articulates what the company is aiming for, and how you’re going to make certain trade-offs. For example, one of our big pillars for this year is how can we scale to 10x volume? As an operationally-heavy company, we want to make sure that we’re scaling with technology, not scaling with people,” she says.

To avoid too many cooks in the kitchen, while maintaining that product ownership culture across the company, Cocoon borrows Apple’s DRI framework. “The notion of the Directly Responsible Individual is that we want everyone to have ownership for the company and the product that we’re building, but that doesn’t mean that everyone is a blocking decision-maker. The DRI is the ultimate person who is accountable for the goal. It’s their responsibility to make sure they’re looping in the right stakeholders, making sure people feel heard, and actually making the call when there are conflicting opinions,” says Feng.

Here’s how it works in practice: “We have four pillars for the year, and we have one person assigned as the DRI for each of those four pillars. They’re responsible for figuring out how we execute and assembling the right team to tackle those problems,” she says.

The key here is to remember that DRI is a fluid role, not a title. “It doesn’t need to be a specific engineer or product person, and someone who is a DRI for a pillar one year might not be a DRI another year. You need to appoint someone who is able to step back and think about the overall goals and outcomes, rather than requiring someone in a specific title or seniority level,” she says.

Debate without ego.

Feng also points out another sprinkle of Stripe on Cocoon’s cake. “There’s a lot of talk in founder circles about hiring nice people, but I don’t think it’s just about hiring folks that are nice. You want people on your team who are kind and generous, but also who aren’t afraid to push back on something they don’t think is quite right or debate passionately for the thing that they believe in,” she says.

After growing up in the Stripe org, where passionate debates were commonplace, it’s a cultural touchstone Feng is constantly reinforcing at Cocoon. “Patrick Collison built this relentless culture of questioning what we were doing and whether it was the highest impact thing,” she says. “At Cocoon, we talk internally about debating without ego. It’s not about being prideful or defending something just because it’s your idea. But we want folks to speak their mind without being afraid of being seen as ‘not nice,’” she says.

And if you’re struggling to come to any sort of consensus, try taking it back to square one. “Sometimes you need to narrow down what you’re actually disagreeing on. Maybe one of us is missing context or information, or we’ve misunderstood what the goal was supposed to be. It’s about maintaining mutual respect and high trust for one another, even when you disagree,” says Feng.

This article is a lightly-edited summary of Amber Feng’s appearance on our podcast, “In Depth.” If you haven’t listened to our show yet, be sure to check it out here.