Onboarding Remotely

I’ve almost finished my first three months as a Product Manager in a new company. While I’ve had some flexibility in work location in the past, this is the first time I joined a company without meeting anyone in person. 

Before I Started

The entire recruiting process took place online, including a full day of Zoom interviews (9am-4pm with a few half hour breaks and an hour for lunch). My phone, laptop, and swag bag arrived the week before. I tried to setup the laptop on Friday as there was training Monday morning, and I found out that it couldn’t be done until I was officially in the system. Remote or not, I’ve often had a day or two of computer issues when joining new companies. My guess is that it’s in part because IT can’t even setup your computer until you’re officially in the system as an employee. Some people never show up.

First Day

Once I got my computer setup on Monday, in time for the formal training with 80 other new hires over Zoom, I still couldn’t access most of the systems the training covered. Apparently it takes 24–48 hours for permissions to filter from the central system out to the other tools. The first day was very broad with all different kinds of employees being told about their benefits and the systems that are used across the company.

Getting to Know the Culture

On the one hand, it’s nice not having to nervously head into the office on the first day, and instead comfortably attend from home. On the other hand, it feels weird to be starting a job and not grabbing lunch with my new manager and coworkers.

Before I started, my new manager said that she didn’t expect me to get anything substantial done for at least three months, which was advice she’d been given by her manager when she had joined eight months earlier. At first this was disheartening to hear, but I think it reveals a lot about the expectations of the organization. We’re managing people’s money, and that’s not something where it’s ok to “move fast and break things.” While the organization wants to be agile, the most important thing is to be safe and risk averse. In order to excel here, I first need to understand the company, its culture, and how things get done. Once I have a firm grasp on that, then I can start to build things within a risk-mitigating framework that is a bit more extreme than other places I’ve worked.

Getting to know the company culture takes a couple of different steps. There’s the formal / written / documented culture, and then there’s the day-to-day way things work. There were ten core tenants of the company which include things like the best people. There are also informal things that you hear repeatedly. For me, the risk focus was what jumped out the most. The company emphasizes risk and would prefer to minimize downside even at the expense of decreased upside. In addition, I both experienced, and then heard expressed a few times that Product Managers here are “nice and smart in that order.” This isn’t a show off how smart you are culture, it’s a be collaborative and friendly culture with an expectation of intellectual horse power as a prerequisite but not the thing you need to be showing off.

How Information Moves Through the Organization

Different companies work in different ways, and so it’s important to find out how people communicate and ideas get cascaded down and up in any organization. In my new company, Confluence is widely used to track projects and processes.

Slack channels are the primary way that teams and indviduals communicate with each other. Even project launches and big announcements are often conveyed via specific slack channels (different from other places I’ve worked).

Share outs are weekly events where Product Managers from across my area of the company share their vision, success metrics, and roadmap for their product. I really enjoy these as they give me a deep dive into what a lot of other people are tackling and the way they’re setting themselves up for success. It also gives the Product Manager a chance to get feedback from across the organization and solicit help and brainstorming in areas where they may be struggling.

E-mail is not intensively used. My manager explicitly told me not to expect a response to an e-mail for a few days at least. I get a lot of alerts, so spent a fair amount of time figuring out which ones were actionable, which ones should be deprecated, and which ones should have filters setup to avoid falling in my inbox but could be useful.

Documentation

When you first join a large company, you’ll often be overwhelmed by a deluge of documentation on the teams, products, and processes that exist within the organization. Don’t feel like you need to read everything thoroughly, but do at least understand the information architecture and do a quick skim of things. Later on, when you’re confronting a new challenge, you want to be able to recall “I think I saw something on this in X Google Doc, or Y Confluence page.” It’s fine to ask questions, especially at the beginning, but the more you can become self sufficient, the more your coworkers will begin to value your contributions.

Find Something to Do 

While my manager had indicated she didn’t expect anything substantial for three months, that doesn’t mean I couldn’t find a way to add value on a small level. The first thing I did was start to take detailed notes during the meetings that I participated in, and then share them out to the group with Action Items and Key Takeaways highlighted. I don’t have to know everything about how the organization works to know what was said in that single meeting and share it, especially for those who weren’t able to attend.

Next, I found a small change in the product space I now own that had already had some thought put into it. Designers had worked on mockups, but their wasn’t any dedicated product or engineering focus, and so it had been shelved for a few months. I met with the designers, dusted off the mockups, and suggested integrating these product improvements with the current user experience instead of the white space designs they’d previously mocked. I didn’t have engineers specifically dedicated to my area of product focus, but I knew I could advance the project, so that once engineers joined my space a couple of months later, we were able to hit the ground running and have a clear vision for the first customer problems we could solve. Even if I hadn’t gotten engineers onto my team, I’m confident I’d have been able to work with an adjacent team to build out this feature because it adds value for their customers. It’s something that users are requesting , and there’s even a mandate from a network that this be available in the next year. When there’s a clear customer problem to be solved, other product managers and engineers get excited to solve it even when it’s not the main thing they’re being measured on.

Meeting People

This is probably the most important piece to focus on in remote onboarding, because it’s so much different from when you’re in the office. Meet & Greets via Zoom are not the same thing as coffee chats in person, but people are open to them and it’s necessary to expand your network. I’ve had 73 of these sessions over the last three months, and I always finish by asking who else should I meet?

It’s important to use these not just to find out what people are up to and how you might work together, but also to try and make a bit of a personal connection. When there’s time, I try to spend a few minutes discussing their life outside of work. Where are they living, what do they like to do for fun, do we have some shared interest?

In addition, don’t just stop with the meet and greet. Schedule follow ups with people that you’re clearing going to be working closely with. This first meeting was just a get to know you short session, the next one you can go deeper into the work that they’re doing, and starting to understand their problems and their customers problems where you might be able to help.

Virtual team lunches and coffee breaks were already setup for my development team, and these have been a great opportunity to get to know the group dynamics outside of formal interactions. Not everyone can make every session, but I really prioritize these on my calendar because I haven’t met these people in person while they’ve mostly worked together in the same building for months or years. If this isn’t something that’s already happening, you should suggest it! You don’t want to be the annoying new person but honestly I think everyone in these times appreciates some breaks in their day and a bit of the old “water cooler” chat that’s been lost in remote work.

Remote for a While

On my second day, the CEO sent out a company wide announcement that we would not be going back into the office until September 7th at the earliest, and there would be six weeks of notice before a return to the office, allowing people to decamp from cities if they wanted. This has now been pushed back to the beginning of 2021. So I know I’m going to be in a remote only world for at least the first seven months of the job. At first, this was a little bit nerve wracking, but I’ve come to realize there were some benefits. Because a lot of the teams I’m working with are based in other cities, if I had joined in normal times, I would’ve been the one face on a screen while everyone else was in the conference room. Now we’re all on a level playing field working from home. It was also faster to get onto everyone’s calendar because I didn’t need to wait until I traveled to the cities where they were located. While I certainly don’t want to continue working remotely forever, I’m at least able to find some bright sides in this weird situation.