Ask HN: How to succeed as an IC at a larger company

[kotojo]

Hiya, I've been doing software development for about 5 years now, but always at smaller companies. My last company had about 25 developers on a single product and that was largest team I'd ever worked on at that time. I'm now working on team with closer to 250 developers across 3 locations/timezones and it's extremely overwhelming.

I've been here for about a month now and still feel like I'm mostly just in free falling trying to figure out 95% of what anyone talks about or how to do things. It seems like everything works fundamentally differently than it does for a smaller scale company.

Do you have any advice for short/long term success as a developer that is very new to operating in an environment at this scale?

[seren]

>> I've been here for about a month now and still feel like I'm mostly just in free falling trying to figure out 95% of what anyone talks about or how to do things.

It is fairly normal, every company has its on acronyms, processes, so I would say it is fairly normal to be overwhelmed in the beginning. There is no way you could know in advance their process.

That being said, you should have colleagues available to help you.

Take always a notebook and a pen with you. Whenever there is a word, or process, you have never heard of or are not sure what it consists of, write it down.

Now every few days schedule a meeting with a member of you team, reviews the list, and request explanation/clarification.

Take additional notes for future reference. That's it, in a few weeks you'll feel at ease with what is happening around you.

This is a gradual process, you'll keep learning in the months, years to come.

Then once you feel more at ease, you can push for initiatives, new ways to do things. A newcomer has usually always lots of fresh ideas because is not yet used to how things are done here...

[davismwfl]

I agree with this, and would add: ask the questions now about what does this mean, what do you mean, how does that work here etc... If you wait 6 months and still don't understand because you didn't ask questions, then you will run into problems and people will start pressuring you or isolating you. When you are new, everyone expects those questions and are generally fairly happy to help, and in really large companies it can take a year to become truly competent in the solution. But if you aren't asking questions or aren't understanding, raising your hand about it etc, they will assume you get it and move on. Then you will be judged like you know all the material when you really don't and that is hard to recover from.

Big teams have their own challenges, but in general, you should likely have a small immediate team that is your focus. So while you need to figure things out, don't freak out about things 3 teams over that you don't understand right now. It is really common in large teams that your area of expertise will be focused around what your immediate team works on, and no one expects you to understand all the other team's work. What makes people "invaluable" is that they push to learn the "entire" system (or as much as possible) from each of the teams, which means they become a wealth of knowledge even if they've been there less time than others. This used to be my trick as a freelancer that led to me transitioning to a true consultant when I built my first consultancy. I'd go into large teams, do the job I was hired for but learn the entire system because I wouldn't stop asking questions, exploring etc. Then within 6-9 months many times I knew more than people that had been in the company for years, only because they stayed in their cube and did what tasks they were assigned but didn't ask questions and explore.

[mark_l_watson]

As you are noticing, there is a lot of communications overhead for large teams.

Large code bases themselves don’t have to be confusing though. I worked as a contractor at Google and their system was very dev friendly with almost everything is available/viewable in a large repo with good editing and build tools.

I hope those 250 developers are split up on small teams, with small manageable projects.

[kotojo]

One of the things I am finding is the amount of project freedom and the amount of process and documentation are the inverse of anywhere else I've ever worked.

Most of my jobs have had very straight forward goals of what needs done next, with an endless backlog of already prioritized work. There has very rarely been much documentation around anything though.

This company is more vague high level goals that teams have the ability to figure out any work they want to do that furthers that goal, but there is a very high bar for documentation before, during, and after features are done. Even git commits have a very rigid structure to them!