Working at Big Tech vs. Startups


You know that one saying about driving? Everyone slower than you is an idiot, and everyone faster than you is a maniac.

The same sentiment is true in tech companies.

There's a big difference in the culture of coding for a big tech company versus startups. Every tech company thinks they like to move fast with high quality. But those mean very different things depending on the company. For Big Tech Co, fast might mean six months. Any sooner than that, and (probably fairly) your project could be considered rushed.

Compare that to a startup. "Hey, if we don't ship this feature next week, the client will leave and we won't make payroll."

The culture of the software development cycle is different because the business needs (internal and external) are so vastly different. If you try to bring one into the other, that’s when frustration happens.


Working at Big Tech Co™

I contracted for a Big Tech Co you've definitely heard of through a third party. Our third party was complimented for the speed in which we executed. Shipping major updates once a month was unheard of. Even as a junior developer, I was certainly slower than everyone else, and was still able to actively contribute to meaningful platform updates within three months of my start date.

And yet it still felt so slow. We had to get approval from every team if it was going to affect them. And that was the right thing to do.

The biggest lesson I learned: build consensus early.

How I learned to think about working at Big Tech Co:

  • Work on your communication and think about how to be helpful to your leads.
  • Lower your expecations for speed. Is the security team briefed on what you’re doing? Have they been able to manage the risks your product will add (e.g. checking dependencies and packages you’re adding to the platform)?
  • Expect longer lead times for QA departments to approve (or disapprove) your code.
  • If you don't have an embedded SDET or SDET teams, expect to write your own unit tests (as I believe each dev should be doing anyway).
  • You'll be slower to adopt new tech (which is good in this context), so get pro-level at whatever stack you're using.
    • E.g. if you're using JS, learn about the weird parts
    • Learn the basics of every layer in your stack, like how to move fluidly between DB, to server, to frontend, to cloud
    • If your company has a style guide, get intimately familiar. Teach other people how to follow it (or build a linter that can implement it for you)

In sum, take some initiative in the direction your company wants to go. Never go solo. Get your team and leaders' buy-in. If you try to move on your own, you'll get frustrated and so will the people around you.


Working at Scrappy Startup Inc

More recently, I've contracted with two small startups. Both of them have multiple people on the team, but none are full-time. They are bootstrapped, but with enough funding to actually pay me (hence the contracting).

The biggest lesson so far: speed > perfection.

Big Co tries to feel small (AKA fast and creative) and small companies try to feel big (AKA ordered and stable...or stable enough to keep you there). But startups, especially when they are early and struggling for talent, are begging to be led.

They want you to take initiate and make suggestions.
They want you to deviate from the wireframes by 5% if it's going to save you 50% of the time to get to market.
They want your input on areas that may have nothing to with software. I double as a copywriter and email marketer (previous jobs) and will make candid suggestions about both.

Getting your product out there for feedback is way, way better than coding for a year to craft a pixel-perfect, tested application that no one wants.

If you're building MVP (and it's not B2B or you have thousands of customers banging down your door), then tech debt is okay. Just ship. Get out the door so you're not holding up sales and marketing. Don't worry about optimizing. Refactor only after you've actually proven the concept.

In short, be a leader. Or at least think like one. That's what every organization wants.

Other Blogs