From early stage startup to engineering management

Jun 26, 2021 by Yihwan Kim. 10 min read.

I used to work in marketing. It wasn’t the sophisticated kind where you analyze a catalog of C’s (CVR, CPM, CTR, CPC, CAC, et cetera) or the fancy kind where you ponder things like brand equity and strategy.

Instead, it was what you get when you let a bunch of driven but clueless 20-somethings apply brute force tactics to disjointed hacks. It was the kind of “marketing” where you throw spaghetti on the wall — followed by the plate, cutlery, wine glass, table, and kitchen sink for good measure — just to see if anything sticks.

Where else could you find 23-year old me working as the “Head of Growth” for a 3D printing company? At an early stage startup, of course.

How I got there, what I actually did, and what ultimately happened is a story for another day. For now, I’ll just say the first year was wonderful. It really is true that you learn more in a month working at a startup than you would a year anywhere else. It became remarkably less wonderful in the final year as our company met the fate of most, falling far short of where we thought our hopes and dreams could carry us.

It’s been a while since my startup days. I left marketing in New York to eventually become a software engineer in San Francisco. Today, I’m an engineering manager, and my day-to-day feels far removed from my years spent scraping leads and consoling irate customers in a tiny pre-war office in the heart of the Garment District.

Yet every day, I’m reminded of how much my time at an early stage startup has shaped how I work — and how I think about work.

Here are some things I keep in mind.

Prioritize — and say no

In startup land, there’s always 100 things to do, but only enough time to do 10. What gives? Well, 90 things. The hard part is choosing which 90, all of which seem so important to do.

So I learned to prioritize aggressively. This meant taking big risks on our initial target market and living with production nightmares until we closed our next round. I accepted that perfection would always be out reach — and focused on making tough decisions to fight another day. It wasn’t easy. I still bear the scars from the crucible, long after I left for cooler pastures.

In a final interview for what would become my next role, I lightly prodded the then-CTO for increasingly specific details on CAC, LTV, runway, and more. He seemed mildly bemused that a software engineering candidate would ask about such things, but graciously answered each and every one of my oddly esoteric questions, going so far as to show me detailed charts illustrating every conceivable marketing and business health metric going back years.

The data showed me the company’s unit economics were strong. I wouldn’t have to worry about cash in the bank. The lights would stay on. Our runway was so long, and so easily adjusted, it might as well have been infinite. With all these resources at our disposal, we are limitless, I thought.

It’s true that not having to worry about making payroll is nice, one of those little things you tend to take for granted until it vanishes from underneath you. But by fixating on dollars and runway, I’d overlooked another resource, one that is arguably far more valuable and scarce than money.


In software land, there’s always 100 things to do, but only enough time to do 10. I learned this the hard way. My first project seemed relatively simple at first, but I started discovering regulatory nuances that gradually made everything more complex. It also involved multiple internal stakeholder groups, each with unique needs and ideas for how the product should work. Veterans already know how this story ends.

Our company was too small to have dedicated product managers at the time, so I happily filled the role. After all, I was still a marketing person at heart — I can talk to people! So I dutifully met with our General Counsel and other internal users, carefully recording every feature request and requirement. Could we have this? Yes, of course! Can we make the system do this? Sure, why not? We have runway, people!

In short, the project turned out fine. We shipped, and we celebrated. But the road to get there was far more painful than it should have been.

After muddling through an endless sea of user stories, I learned to scope down to an MVP. After taking flak for requesting a review on a 2,000+ line PR, I learned to ship early and often. After stepping on code landmines (and creating a few myself), I learned to nimbly react and adapt to unexpected circumstances, including the ominous “system down” alerts that strike every new developer with an indescribably deep and totally paralyzing fear.

My first few months as a newly-minted software engineer were some of the toughest in my career, rivaling my most arduous months at an early stage startup. But in both experiences, I found an unexpected commonality. I could get through it all if I prioritized, not just feature development, but what I learned and when, what I worked on, and what I promised others I would do.

I had never been a software engineer before, but I knew how to prioritize. I could do this; I had done this, I told myself. And so, I did.

As our company grows, and we hire actual product managers, more engineers, designers, and even a dedicated product operations team, the need to prioritize remains. If anything, it’s increased. I’m careful not to make the same mistake in thinking that having more resources means you no longer have to prioritize.

Prioritizing and saying “no” go hand in hand

At an early stage startup, saying “no” was introspective. Everyone knew that 90 things wouldn’t make the cut. So in a way, we were saying “no” to ourselves. When we needed to make these tough calls, the entire company — all 10 or so of us — gathered around a whiteboard to discuss trade-offs, consider consequences, and ponder the enormity of the tasks before us. We didn’t always agree, but we committed to decisions as a group.

At larger companies, these trade-offs are less visible, and total consensus is practically impossible. Saying “no” becomes a more external endeavor, fraught with all the complications of interpersonal communication. Even so, saying “no” remains more important than ever.

It’s just as important to learn how to say “no.” Sure, it’s not great to say “yes” to everything (I learned my lesson). But at the same time, I chafe at the stereotypical obstructionist engineer. You know who I’m talking about: the one that designers and product managers avoid in the halls; the one that tells everyone within earshot that no, their ideas are impossibly complicated, too expensive, and would take far too long to ever come to fruition.

A long time ago, someone told me that I should learn to say “no” while making it sound like I’m saying “yes.” It was puzzling feedback then, but I’m finally beginning to understand.

While the art of saying “no” could fill an entire post, maybe a book, here are some highlights I keep in mind when I have to turn down a colleague’s request:

  • It doesn’t have to be a negotiation. Don’t split the difference and call it a day. Instead, take a step back and focus on the goal. Is your goal aligned with your colleague’s goal? If not, that’s weird. At high-functioning companies, everyone’s mission and higher-order goals should be aligned.
  • After you’ve aligned around a common goal, explore why your colleague thinks their request is the best way to achieve that goal. Sometimes, you collectively discover a better way to achieve the goal without ever having to say “no.”
  • If you can’t agree on an approach, try to at least agree on the trade-offs. Explain why the request would be challenging, share your understanding of the trade-offs, and listen to theirs. If you can align on the trade-offs, you’re officially on the same side and better positioned to unite around a solution.

I’ve almost never categorically shut someone down with an obstinate “no.” When time is the chief constraint, the answer is usually more along the lines of: “yes, we can do that — but that would mean we can’t do this other thing.” I never say “never” when the answer is really “not now.”

“No” should not be the end of the road. Instead, it can be a minor juncture where you sit with your team and collectively decide the best path forward. If you do it right, it really does sound like you’re saying “yes.”

Trust your team

Congratulations! You now only have 10 things to do. But if the 100 things you started with were important, these 10 are absolutely mission-critical — and if you thought prioritizing these tasks was hard, now you actually have to do them.

When your entire company is 10 people, assigning tasks is surprisingly simple. Each person takes a thing — their thing. Each person takes complete ownership over their assigned task and does anything and everything to get it done. Otherwise, you’ll let your entire team down.

I don’t necessarily recommend this kind of pressure cooker environment for everyone. It’s rather stressful. But if there’s a silver-lining in the debris, it’s that I learned what it means to have an ownership mentality.

When you’re the owner, your thing is your problem. You don’t get to say that you’re waiting on something else, that someone up the line messed it up, or that everything is just so unfair. This may all be true, but it doesn’t change the fact that your thing is still your problem. Thinking like an owner means making sure your problem is solved, no matter the obstacles.

There’s a fine line between taking ownership and taking control. It’s not that you have to do your thing, but rather ensure that your thing gets done. More often than not, this involves empowering others, collaborating with and sometimes persuading those around you, and trusting that everyone else is thinking like an owner too.

Owners need to be flexible. Priorities change, remember? They change all the time. So if your thing is suddenly not so important any more, having an ownership mentality means dropping it without too much of a fuss, all in pursuit of your team’s greater goal. Sprinting down a single-track is great, but you need to be able to move between tracks just as swiftly.

I know this all sounds a bit oorah-y. In reality, things aren’t always so clear-cut. Also, I’ve gotten to the point in life where I have a preference for down pillow firmness. I don’t think I’d make a great Marine. But I’ll forever appreciate how working at an early stage startup firmly imprinted an ownership mentality in my mind, however Marine-like that might sound.

As an engineering manager, my challenge is scaling that mentality — and trusting my team to make it happen. How can I empower others to think like owners?

I start by focusing on the goal, not the process. I emphasize outcomes, not activities. I make sure we all know where we’re going — and that we want to get there. How we get there is really up to you.

I try to set my team up for success. Letting people forge their own paths doesn’t mean stranding them in the woods. At the same time, I remind my team that my job isn’t to solve problems or answer questions. Instead, my job is to make sure problems are solved and questions are answered.

Sometimes, this involves connecting people to senior staff engineers and technical experts. More often, this means sitting down with my team, revisiting our goal, and thinking critically about the best way to get there together. My goal is for the team to carry on with this on their own, rendering me redundant. I hope they can all be owners one day.

Things don’t always work out. I like to think I’m pretty clear about that. Projects go south; systems go down. But where people might fail, I ensure that the stakes aren’t too high — so they can fail gracefully. After all, we can learn a lot from failure. And where we fail gracelessly, it is mine to bear.

The ultimate goal is not only for me to trust my team — but for our team to trust each other. The goal is to create a team that truly believes they can do anything and everything if they set their minds to it. If you can get there, the feeling is truly magical.

Keep perspective

With the benefit of hindsight and a more generous buffer between past and present, I now have perspective. If I could reach back through time and talk to my younger more naive self, I would tell him this:

It’s going to be okay. Even if everyone and everything is screaming at you that it’s not, you are going to be okay. Even if it feels like the sky is falling with no shelter in sight, you are going to be okay. Even if in the end, your company — along with everything you’ve hoped, worked, and sacrificed for — flames out and craters into oblivion, you are going to be okay. No matter what happens, you are going to be okay.

While I couldn’t have foreseen it at the time, working at a (failed) startup has given me a near superhuman resiliency to any curveball my career hurls at me. I still get frustrated at work, sure, but I always pause and ask myself: hey, how does this compare to that time you thought your life was over because you couldn’t close a sale? I chuckle and get back to what I was doing. Whatever the issue, it always seems so much smaller in perspective.

After giving my former self the gift of perspective, I would say: be kind.

The older I get, the more I realize that not much matters: not life’s lowlights, nor the highlights. It’s not going to matter that you took down production (as scary as that was) — or that your company went bankrupt (as devastating as that was). It’s not going to matter that you improved site performance by x%, no matter how many dollars that saved the company — or put in your own pocket. In the long run, none of this will matter.

The only thing that matters, I’ve learned through intense trial and error, is how you impact the people around you — the community you create, and the connections you make.

I cringe when I think back to all those tense meetings, some of which devolved into shouting matches and ended in tears as our company entered its penultimate days. I feel waves of contrition when I think about how I berated developers for missed deadlines and broken promises.

Oh, the irony now. If I had only known that none of this would matter, and that we would all be fine in the end. If I had only known to be kind.

It’s a lesson, perhaps the one lesson, I will never forget. Don’t let your emotions affect how you treat others. Don’t make mountains out of mole hills. Have difficult conversations, but don’t make them personal. Don’t neglect relationships outside of work. Be kind. Keep perspective. Do this — because everything else doesn’t matter.

It may seem strange to say and even harder to accept. But once you do, it’s incredibly liberating. That’s perspective.

I laugh while I write this because the last thing I remember about working at a startup was barely escaping the wreckage, muttering to myself, never again. I would never subject myself to the chaos and trauma of working at an early stage startup.

I probably won’t. My risk-reward profile has mellowed out as the years have gone by. But every now and then, the sacrilegious thought creeps back into my head. What if? The temptation is especially strong now, as I type this out in the heart of the Bowery, just a couple stops away from my old startup’s office in the Garment District. Rose-colored glasses are a dangerous thing.

Whatever happens, I will forever be grateful for my time at an early stage startup. I just wouldn’t be me without it.

Comments? Thoughts? Let me know! @yihwan 🐦

© 2021–present Yihwan Kim. All Rights Reserved.