On-boarding and Doing the Work that Nobody Wants To Do

Herry
7 min readJan 26, 2016

--

Starting a new job is daunting. Typically you won’t really know what you will be working on until you get there. If you’re lucky, your job will have a good on-boarding or training process to prepare you. In most organizations, however, this will not be the case.

Usually your boss or one of your colleagues will try to give you a summary of everything that is happening and what you are responsible for. The problem with that is:

  1. there is a ton of ground to cover
  2. your boss or colleague is way too busy as it is without having to hold your hands through your first few days

I remember at my first job, my boss spent thirty minutes with me before having to run to his meetings. During that time he sent me documentation to peruse and left it at that. As instructed, I tried to figure things out on my own by reading specs, going through the codebase, and googling things I didn’t understand. I didn’t want to bother anyone, but I eventually had to cave because I wasn’t getting anywhere on my own. I asked the people around me for help, but everyone had responsibilities and deadlines to meet, so they couldn’t spend too much time with me.

I heard similar stories from my friends. One told me that his boss sent him to shadow his coworker for a few hours as his on-boarding exercise. Since his coworker was engrossed in his work, my friend had very few chances to ask him any questions. In short, it was a waste of time for both of them.

So how will you get up to speed with everything?

What you have to do is to get your hands dirty first. The fastest way to get up to speed and become productive is by doing the work that nobody else wants to do.

Write and Take Notes

One of my many early mistakes: getting someone’s name wrong

If you’re in a role that requires you to attend or lead a lot of meetings, be the person taking meeting notes. If there is another person assigned to take notes, offer to do it for them. I’ve met very few people who genuinely enjoy taking notes, so you would be doing them a favor. The goal is for you capture as much information as possible and make sense of it later.

During my first few weeks as a Product Manager, I was invited to a lot of meetings. Our company was in the process of shipping our mobile app, so things were very hectic. People launched into the meetings without giving me context beforehand. The result was that I had no clue what was going on, so I often stayed silent during those meetings. But that didn’t mean I couldn’t contribute. I recorded the conversations meticulously, even if I didn’t understand what everyone was talking about.

I made it a habit to send out the meeting notes right after, knowing that I probably misunderstood a lot of things. As expected, my teammates brought those mistakes to my attention after the meeting. It was embarrassing of course, but their callouts provided me the opportunity to ask them to explain the things that weren’t clear to me and probe deeper to understand.

Communicating things clearly in the notes will help everyone on the project execute better, so your coworkers are more incentivized to help you. On top of that, you now have a written account of ongoing initiatives, so you are that much more ahead than if you had sat back and stayed out of everyone’s way. You’ll find that if you commit to this and aren’t afraid of making mistakes, you’ll start to get sense of what’s going on very quickly.

Test and Provide Feedback

If you are working at a software company, you can ask to test some of the new features coming out. Everyone appreciates an extra set of eyeballs on their work, especially fresh ones. Since you are new, you wouldn’t have all the biases of having worked on or heard about the feature. Your honest opinion could turn into a tremendous contribution.

In my case, my team asked me to look at a video recording feature that they were getting ready to launch when I first joined. The premise of the feature was that you could take any one of your YouTube videos and record an up-to-30 second trailer clip and post those clips as native Facebook or Twitter videos.

I started playing around with it, and within a few seconds I was already somewhat frustrated. There was a mandatory seven-step guided tutorial I had to walk through before being able to use the tool. My team could sense my impatience as I was furiously clicking my mousepad.

The video recording feature

I asked them why they decided to include the tutorial, to which they responded:

“Well our users might not get how to use it.”

I argued that anyone’s first instinct would be to click and hold the big button in the middle, and from there on out it becomes fairly clear what the feature does. Take Snapchat for example. There are no instructions posted, but most users get it after playing with it for a few seconds.

The majority of our users are also millennials, so I was certain that they’d be savvy enough to figure it out without having to sit through the lengthy tutorial. Before we launched the feature, we got rid of the guided tutorial, and created an optional video that the user could watch by clicking the (?) on the top left.

It turns out that this bet paid off as the feature became one of our most used feature in the product.

Testing and providing feedback allows you to get involved in a meaningful way and contribute right off the bat. The best part is that you can do this regardless of what position you were hired for.

Meet and Improve Processes

During your first week you should try to schedule coffee or lunch with as many of your teammates as you can. The goal of these 1-on-1’s shouldn’t be your asking for help. Instead, these meetings should be focused on what your teammates’ needs are, what is working for them, and what could be improved.

Focus especially on the things that could be improved. As a new person, you have the ability to breath fresh air into existing processes. It becomes much harder to do this as you become more entrenched in the company.

At my current job, there was an unspoken rule that the business team shouldn’t ping our developers. Instead, they were supposed to go through the Product Manager first. The rational was that developers needed undisturbed time to work on their assignments, and wouldn’t be able to produce quality output if they were bothered all the time.

This was a particularly big point of frustration for the business team because they would often have to wait for hours or days on requests that could have been done in a few minutes if they could work with the developer directly.

Although I see the rational to protect the developer’s time, I didn’t think this process was very conducive to team building. I decided to let everyone from the business team work with the developer at their discretion, but to be mindful of the developer’s time. This resulted in much higher reported satisfaction for both teams, and all it took was for the new person to become a champion for the new process.

Don’t just assume the status quo is good. Be the catalyst to make things even better.

I did a lot of these out of necessity at first, but to this day, I am still the person who takes the notes, tests all the features before they go out, and check-in with everyone from time to time. These tasks may seem mundane and unimportant because no one wants to do them, but I found that these are the little things that have a massive impact on my performance.

So whether you’re starting out, or trying to become better, look at these as tasks as opportunities for you to become an invaluable member of your organization.

If you like what you read, be sure to recommend it by clicking the ❤ button below.

--

--

Herry

Adventures in product management and life. Product Manager @Facebook | Writer | Fitness Enthusiast | @Stanford Alumni