Setting Up for Success in a New Job

Joining a new company is always a daunting endeavour. From remembering new names and faces to learning about different processes from what you are used to. And even just acclimating yourself to understand the jargon, documents, and charts. Some companies may be documentation rich, while some are agile ad nauseam, and some may be a google-your-way-out-of-it kind of place where “we all wear many hats.” Navigating through these challenges is the path every new employee needs to deal with in order to ramp up like a pro.

“Always leave the campground cleaner than you found it."

Starting at a new place, you are usually behind the curve in terms of understanding the domain knowledge required for the job. Documentation, however, is where one can contribute early and often to provide great value for your team. It’s an easy win. If there is existing documentation then update and add more on top of it, otherwise create an onboarding document for the next new hire or new team member to consume on their first day.

An added benefit of doing documentation work early is that it serves as a starting point to gaining knowledge over the system you work with. You need to able to explain the process in simple words to someone who has no idea or context about it in order to fully understand it. Explaining a complex idea in simple terms is the definition of understanding a concept.

But where should one start in writing documentation? It depends on the state of the documentation the company has (or lack thereof). If there is already plenty of documentation then just verifying they are still correct and possibly updating small inconsistencies is enough. To go above and beyond, try adding your fresh perspective on the state of things so that the documentation will be more clear.

However, if your new role does not have the tools you need to succeed early then it is likely an opportunity to document your learnings to make it easier to onboard new team members. However, to how start a document is in itself something you need to learn--one that would require prior knowledge on how individuals in the organization communicate with each other.

Learn the Communication Style

Do people usually keep documents on wiki sites such as SharePoint or Confluence? Or is it more of a wild west of emailing a Word document or a link to a Google doc around?

Same goes for communication - what is preferred among emailing, calling, an in-person drop by, in person meetings, slack or teams, video calling, snail mail, or whatever as the de facto mode of communication?

Knowing the answer to both of these would provide you with answers for where to create the new onboarding document, as well as who and how to talk to those who can provide you information to fill the guide up into something meaningful.

As an example, in more technical roles, code style is also something worth getting familiar with. Do developers usually use a certain style guide, or linters, or even a commit style to a version control system such as git? We all usually bring style baggage from our previous jobs or school but it is important to be able to follow the style guide so that the code is consistent. Consistency reduces the mental load for others to understand new code that is created and so that each developer can have an easier time switching between projects by lowering the overhead of context switching.

Design related roles also share a similar expectation to have a similar look and feel to the overall application. This benefits both the users of the application who have to interact with the entire system rather than only sections and fellow team members to be able to create designs that work well with each other. Communication style is key to a successful start since it affects all types of roles in terms of formatting and tone of the text or speech used.

Relationships Matter

As a newbie to the organization, you will likely be asking more questions than answering them at the start. This is okay. Everyone goes through an initial ramping up stage. During this time, it is key to do your due diligence in finding out information on your own through documents or googling it. No one wants to spoon feed information to others if you can rule out the available documentation and conduct a simple google search that brings you 99% of the way there. It would be reasonable and even encouraged for someone new to the project (not just the company) to ask questions if they did their due diligence.

While you are busy making new relationships at your new company, it is important to keep a pulse on your old work colleagues. Try to bring back what you think was done better at your new job to your previous colleagues. And at the same time, bring what you have learned from your old job to your new job to develop a mutually beneficial relationship.

This provides your team with a rare opportunity to see what others in the industry are doing and see if it makes sense to bring in these best practices. In the future, both relationships together will give you a sense of what the industry is doing inside and outside of your silo and provides learned knowledge to make your workplace better.

Starting at a New Place?

Here are 5 quick ways to contribute now (from simple tasks to larger goals):

• Making dumb text links into hyperlinks
• Cleaning up legacy style to follow the company norm
• Ask questions! Sometimes there isn’t a good reason why things are done in a way and you might be the one to provide one (one way or the other)!
• Bring best practices from your outside experience to your new org
• Share your experience with your manager, skip level, and the community as a whole

Did I miss anything? Please comment below to share your own experiences starting out at a new company and what other best practices have helped you ramp up like a pro.