On Building vs Joining

I’ve been going down the startup path over the last 12 months, a very different life to the decades I spent in big tech companies. Someone recently asked me which was “better”, joining an established company or building your own thing. It made me laugh a little, not because it’s silly, but because I’ve spent the better part of 25 years convinced I knew the answer, only to completely reverse my position… twice.

I’m writing this from the other side now (at the moment anyways). After AWS, Microsoft, Dell, after playing the “join” game at various levels and stages, I’m building Adjacent Possible Tech and creating solutions to help in the education space. Nobody tells you the interesting part isn’t which choice is objectively better. The interesting part is how the trade-offs don’t become visible until you’ve lived both sides long enough to stop fooling yourself about what you’re actually trading.

The Things You Trade When You Join

When I joined AWS in 2016, I was joining a rocketship that was already in orbit. I had some public cloud experience, more private cloud for sure, but I was stepping into something that worked. And that “works” does a lot of heavy lifting.

Here’s what you get when you join something established:

The infrastructure is already there. Not just the technical infrastructure, though yes, that too, but the social infrastructure. The org charts, the Slack channels, the written and unwritten rules about how to get things done. When I needed to talk to a service team about a customer issue, there was actually a team to talk to. If I needed legal review on something, there was a process. It might not always be fast, and it might sometimes feel like you’re filing paperwork in triplicate, but it exists.

You’re trading your time for reduced existential risk. At big tech, the company’s survival is not your daily concern. I never woke up at 3am at AWS thinking “what if this whole thing collapses?” I woke up at 3am thinking about customer issues, sure, but the baseline, the payroll, the healthcare, the next quarter’s existence, was handled by someone else. You’re not betting the house on every decision.

The learning curve has been smoothed by thousands of people before you. In my first weeks at AWS, I was drowning in acronyms and unfamiliar concepts, “drinking from the firehose” as the say. But there were onboarding docs. There were team wikis (of varying quality). There were people who’d made the same mistakes I was about to make and had written them down. The institutional knowledge was there, even if you sometimes had to hunt for it.

But here’s the thing about joining: you’re also trading away some things that seem minor until they’re gone.

Someone else is choosing your problems. The projects that get funded, the priorities that shift, the org changes that land on your lap, maybe you can influence them, but you don’t control them. I watched countless engineers at Microsoft and AWS build brilliant things that got shelved because of strategic pivots three layers above their pay grade. Not wrong decisions, necessarily, just not their decisions.

Your upside is capped. Stock grants are great (genuinely great, don’t let anyone tell you otherwise), but you’re getting a percentage of someone else’s outcome. If AWS does well, you do well. If AWS does incredibly well, you do… a bit better than well. There’s a ceiling on how much of the upside flows to you, and it’s set by people you will never meet.

The timeline isn’t yours. Promotions come when they come, again maybe you have some amount of control, but not fully. Projects launch on schedules determined by roadmap planning. You can work harder, work smarter, but there’s a pace to large organizations that you don’t set. Some people thrive in that predictability. Others feel like they’re running with ankle weights.

The Things You Trade When You Build

Building your own thing inverts all of these trades. And the inversion is wild.

I’m nine months into building myEdi.ai now, and the most deafening thing I noticed was the silence where the infrastructure used to be. Need to talk to the legal team? I’m the legal team (or rather, I’m the person who has to figure out how to afford one). Need a marketing strategy? Design system? Customer support process? All of it starts with an empty Notion page and a decision I have to make.

You’re trading reduced existential risk for control. Every decision is mine now. That sounds empowering until you realize it means every mistake is also mine. When something breaks, when the roadmap needs to change, there’s no one else to escalate to. The buck stops at a desk with my laptop on it. And yes, some days that feels like freedom, and other days it feels like I’ve voluntarily signed up to worry about everything, all the time.

The upside is theoretically unlimited. If this works, if myEdi.ai becomes what I think it can be, the returns flow directly to me. No compensation committee, no vesting schedule (well, actually there is, but I set it). The correlation between effort and outcome is as direct as it’s ever going to get in business. Of course, the flip side is that the downside is also more direct. If this fails, I don’t have AWS or Microsoft or Dell on my resume as a fallback. I have a gap year that I chose to spend building something that didn’t work. Thats a big bet!

You’re learning by breaking things that matter. There’s no smooth onboarding when you’re building. No one’s written down the institutional knowledge because there is no institution yet. Every process, every decision framework, every “this is how we do X”, you’re creating it in real-time, usually while also trying to do X. I’ve learned more about design, marketing, education, and child development in nine months than I learned about those topics in 25 years at established companies. Not because I’m smarter now, but because I have to learn. There’s no one else to delegate to.

But the trade-offs work in reverse too. The things you get when building are sometimes the things you’re giving up when you join. And the things that were problems when you joined become luxuries when you’re on your own.

The Part Nobody Talks About: Identity

Here’s the subtler trade-off, the one that took me years to even notice: when you join, especially when you join big tech, your identity gets tangled up with the company’s identity.

For years, when someone asked what I did, I said “I work at AWS” or “I work at Microsoft.” The company name did a lot of heavy lifting in that sentence. It signaled competence, resources, insider knowledge. People made assumptions about my skills based on the logo on my badge.

When you build, you lose that shorthand. Now when someone asks what I do, I have to explain myEdi.ai. I have to make the case for why it matters, why it’s different, why they should care. There’s no institutional gravity to lean on. It’s just me and my ability to articulate what I’m building.

Some days that feels like I’ve shed unnecessary armor. I’m not hiding behind AWS’s credibility; I’m building my own. Other days it feels like I used to walk into meetings with a powerful engine behind me, and now I’m trying to convince people I know how to build the engine from scratch.

The inversion isn’t better or worse. It’s just different. And you don’t know which different you prefer until you’ve tried both.

What Nobody Can Tell You

Here’s what I wish someone had told me earlier: the trade-offs aren’t static. What seems like a good trade at 30 might feel terrible at 40. What feels like unbearable constraint when you’re building something might feel like blessed structure when you’re burned out.

When I joined AWS in 2016, I was trading away some control for institutional support, and that was exactly the right trade for that moment. I needed to be in the room where cloud was happening. I needed to learn from people who’d already figured out things I didn’t even know I didn’t know.

Now, in 2025, building myEdi.ai is the right trade for me. The control matters more than the safety net. The direct connection between effort and outcome matters more than the smooth infrastructure. The ability to choose my problems matters more than having problems chosen for me.

But I’m not delusional enough to think this is the final answer. Five years from now, I might join something again. Or I might build something different. The point isn’t to find the universal truth about building versus joining. The point is to figure out which trade-offs you’re willing to make right now, with the information you have, for the life you’re trying to build.

So, which is better?

When someone asks me now which is better, building or joining, I find myself saying “Yes…”.

Yes, join something if you’re trying to learn faster than you could on your own, if you want to see how things work at scale, if you need the stability to take care of other parts of your life. And be honest with yourself about what you’re trading away: some control, some upside, some direct connection between effort and outcome.

Yes, build something if you’re ready to trade stability for control, if you’ve learned enough to know what you don’t know, if the thing you want to exist doesn’t exist yet and you can’t stop thinking about it. And be honest with yourself about what you’re trading away: the infrastructure, the reduced existential risk, the smooth learning curves.

The interesting question isn’t which is objectively better. The interesting question is: what are you trying to optimize for right now, and which trade-offs serve that?

Because here’s the thing about building versus joining: both paths work. Both paths fail. And which one is right for you changes more often than you think it should. The only wrong answer is pretending the trade-offs don’t exist.