
Ask HN: How to succeed as an IC at a larger company - kotojo
Hiya, I&#x27;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&#x27;d ever worked on at that time. I&#x27;m now working on team with closer to 250 developers across 3 locations&#x2F;timezones and it&#x27;s extremely overwhelming.<p>I&#x27;ve been here for about a month now and still feel like I&#x27;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.<p>Do you have any advice for short&#x2F;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!

