Ask HN: Moving from a startup to a big co, what should I be aware of?

Truest comment here. I’m co-founder at tesults.com and the biggest reason we discovered for dropping off the product is because upon integrating they realize their test automation is in such a bad state there’s no need for the service :-) It’s a shame because regression is commonplace. I wrote about why I think it’s done badly on the blog (https://www.tesults.com/blog?id=why-automated-test-projects-...)

I’ve worked at companies with 100k workers down to 10 people companies and the employee is generally a cog everywhere unfortunately but you learn different things. I started out in big companies and learned nothing about the business side of things whatsoever in those years. I did learn solid technical skills and practices though. I think smaller companies are the way to go if you intend to do your own thing one day. Bigger is better earlier in the career to learn technical skills or later on if you need a comfortable/well paying job when raising kids for stability.

I've done a startup, a couple of midsize companies (~4k engineers), and AWS. Just my 2c, a lot of the advice I'm seeing here applies more to the midsize companies than at least my corner of AWS.

In my Amazon experience:

* Some very high level project requirements would come from above (e.g. after this date, internal technology X is being deprecated, so you should have a really good reason to put out a project with X).

* Otherwise, decisions were mostly made at a low level, documented, debated with the wider team for an hour, then implemented. This was a little more structured than at the startup, but most of it was that documentation and debate happened before implementation, rather than after implementation at the startup.

* Project managers were somewhat active with the team, but a lot of the features we worked on came from the engineers watching what was used, forum requests, or customer requests through other channels (e.g. conferences).

* There was a focus on getting products out quickly, but tech debt/tests/reliability was a much bigger focus than anywhere else I've been.

* The team was fairly small, and encouraged to make heavy use of other team's internal tooling/native AWS tools for anything that didn't really need to be custom. Interactions with those teams was pretty straightforward and mostly supportive- "We're using your service to do Y, and would like to do Z too, but that doesn't seem possible without some tweaks to your API/service, is that something you can put in the backlog to investigate?"

* An individual team could be quick to change, but the organization as a whole has a lot of cultural momentum in the way things are done, and it's not clear who to talk to to make recommendations. For example, at the startup, I could go to the CEO and express concerns about the newly restrictive information security policy. At Amazon, I'm probably not going to email Jeff Bezos and suggest six-pagers be made available in advance of meetings.

* Transferring teams in Amazon is mostly extremely easy

* Conversely, Conway's law applies hard in AWS- it didn't seem straightforward to offer products or features that weren't obviously under one team's purview without forming a new team.

here are some things I've learned:

* politics: yes, they exist everywhere, but tend to be amplified at larger companies. polish your political skills, and one thing that I've learned is that it's important to "show, don't tell"

* fiefdoms: there are more of them, some more welcoming than others. be prepared for those that value power above all. you can't take it personally, or you'll go into a very dark place; "be the rubber duck", that is, stay floating no matter what and let the negative wash off of you like water off a duck

* duplication of effort: there likely will be tons of duplication of effort (even parallel projects doing the exact same thing), sometimes it's easy to work with others and come together for a common solution, sometimes it just plain won't happen (see fiefdoms). no real advices here, just that you need to be aware

* technology stacks: sometimes some groups will be stuck with what seem to be very old technology stacks, or things that don't seem to make any sense. look at the group you'd be joining and who they interact with, find out about the pain points before you join so you aren't surprised. even a small change can affect a lot of people at that scale, so approach changes and modernization gingerly.

Try to intuit what your boss and your part of the organization really values. By that I mean what they like and reward, not what they say is important. Understand the difference.

Having a quirk or two is fine, it shows confidence. But you cannot be out of step in too many things, even if it compromises your effectiveness.