Beginnings, like this one, are important. A good beginning draws you in, puts you in the right frame of mind to engage with upcoming ideas or events, and makes you want more. A good beginning might be funny, action-packed¹, raise burning questions, make you feel a need, or enrage you.

A bad beginning doesn’t do any of those things. A bad beginning is there because a thing has to start somewhere. If it didn’t start with Chapter 1, suddenly Chapter 2 would become Chapter 1. A bad beginning is not interesting, not useful, not repellent. It might be a bit clunky or it might not. It just starts the thing, but only because it’s the first part of the thing it’s starting.

To be sure, good things can start with bad beginnings, and good beginnings can lead to bad things.

The beginning of a new job is often called “onboarding”. But that term means different things at different companies, or even in different departments within the same company. A few months ago, I started at WP Engine. As a new hire, I went through a process called “New Employee Onboarding” or “NEO”. It’s a couple of days of getting all the new-hire stuff handled, communicating culture, and making sure that you can at least communicate within the company. It’s done pretty well. But after NEO is done, there’s more onboarding to be done: the new hire reports to their team to “onboard” there. That’s where it moves beyond understanding the company, and into getting up to speed on the actual work.

Neither of the onboardings I’m going to write about involved WP Engine.

Both of the onboardings I’m going to write about strongly influenced my view of the company I was joining. Think about that for a second, by the way. I had interviewed. I’d met people. I’d read about the company. I’d asked my questions. I’d already formed a positive view of the company and said “yes” to an offer. And even so, the onboarding process did far more to influence my view of the company.

Two onboardings means two companies. I won’t name them, though it’s probably possible to recognize them if you worked with me at either. Let’s call them “DC, Inc.” and “Marvel, LLC”. Both were remote jobs, and in both I had a senior role in software development.

Got that first-day-of-school feeling? A little nervous, a little excited, hoping that nobody will steal your lunch money, and hoping that the school lunch is good this year? Great!

DC, Inc.

I logged into Slack on my first day, a few minutes before the agreed-upon time and took a quick look around. People I didn’t know, talking about projects I didn’t know about. No surprises. Great. I messaged my new boss. Good morning, Bruce. I’m ready to work. Where to start?

We hopped onto a Slack call and talked for a bit. Bruce was excited to have me on the team. I could tell, not just from the words he used but from how he talked and what he talked about.

I’d be working on a project that had a team very much in transition. It turned out that I was replacing someone who had recently left. In the meantime, Bruce was filling in. The other member of the team, Diana, was moving to a different team soon. We had about a week of overlap. But it also turned out Diana had something going on that week (maybe PTO? I don’t recall exactly). So we pulled Diana into the call and made a plan for my first week.

Bruce had meetings or PTO or other teams that needed some attention that week. So on Monday, Diana would get me oriented in the code, make sure I could access all the cloud platform resources I needed, walk me through the project, and hoped to have me set up to do something productive-ish that week while she was out. Bruce would check in every so often throughout the week, and then week two would be more normal. Me, I had no context to argue. It felt a bit chaotic, and a bit like I was working without a net. But it also made sense given our current constraints.

Great! We’d agreed. Diana helped me get my editor set up, got me into Github, gave me some access in our cloud platform and helped me request a bit of additional access, explained the project context and architecture to me, suggested my first commit (I believe we’d found a typo in some of the Getting Started instructions in the developer’s readme), and helped me deploy following my change (spoiler: changing the developer’s readme makes for a pretty safe deployment). I noted how nice it was that the development and deployment docs were in the project repository, and that the docs were genuinely useful. Somewhere in that day, I got to meet the rest of the DC, Inc. crew. They all seemed pretty nice and happy to meet me.

Cool.

Tuesday through Thursday or Friday, I was pretty much on my own. As planned, Bruce would check in every so often. As I recall, I was working on some throwaway Python scripts to prove out an approach to data extraction from a third-party API that we’d later re-implement into the core product in the project language (which was definitely not Python). I worked, and I talked with Bruce when he was free, and I asked a few questions here and there, and I ended up with a few hundred lines of mostly-tested Python that would get and transform the data we needed. Bruce seemed happy about what I’d gotten done.

Also cool.

The next week, Diana had moved to her new project. Bruce’s calendar had cleared up. We were able to get into the new normal rhythm. The DC, Inc. normal way of working was regular pairing. For my first week, I really hadn’t paired much. So in week two I learned what it was to pair remotely for most of the day.

Loved it. It was hard work, but I loved it. Questions never lingered more than a few minutes. “Hey Bruce, why are we building it like this?” I never got too far away from the existing design—or, when I did, it was because Bruce and I had already talked about how the design needed to change. Any confusion about the test framework got cleared up pretty quick.

Though, come to think of it, I do remember writing a half-dozen functions to transform some data that were pretty darn clever while Bruce was in a boss-type meeting. And when he came back, he observed that those didn’t need to be functions. They could be done inline using existing language features. And they’d be more readable.

Darn. He was right. But that was cool too. I learned. And got to delete a few dozen lines of code.

One of the interesting things about the whole onboarding experience was that I was included. Part of the team. Expected to make mistakes at the same time I was expected to contribute. My questions were answered (repeatedly), my jokes were tolerated (sometimes even laughed at), my contributions noted, and it felt great.

A few months later, another team needed Bruce. We’d hired Kara and onboarded her about a month after I’d joined. So Kara and I, with maybe six months of total experience at DC, Inc., were the new team. Bruce was available for questions, sure (so was Diana, for that matter).

And it worked out. Sure, I was senior and of course I’m pretty awesome. But that’s not why it worked out. It worked out because we had really been onboarded. We had enough knowledge about the product we were building, the problems it was trying to solve, the business context we were operating in, and the cloud platform we were building on. We could be responsible for the product. We could have in-depth discussions with other stakeholders. And we did. Like I said, it worked out. Nicely.

Marvel, LLC.

I logged into Slack on my first day, a few minutes before the agreed-upon time and took a quick look around. People I didn’t know, talking about projects I didn’t know about. No surprises. Great. I messaged the CTO, the guy that had hired me and the one person I knew there. Good morning, Tony. I’m ready to work. Where to start?

It turned out I needed to start with some machine set-up, HR-type training videos, and other “getting started” things. Solo work at Marvel, LLC. So I headed off and got started.

Somewhere during all that, my team lead, Clint, gave me a call on Slack to say hi. He pointed me to some of the repositories I’d be working with, said he’d get me invited to stand-ups and other meetings, explained what our team was working on, and said he was glad I was part of the team.

And I got to meet my manager, Scott. He gave me some introduction to the company and talked a bit about some areas he was interested in picking my brain on.

Cool.

The next few days were frustrating. I met my team. That was nice. But I felt awfully lonely at work, even though I remember noting how friendly and willing-to-help everyone was. It seemed like a lot of things were difficult. Some of the training videos seemed to assume context that I didn’t have. I needed to get set up on a certain system to access my softphone. But when I asked IT for help, they kept calling my softphone to try to help me. They left a message, though, so all I needed to do was access my softphone and listen to the message. In other areas, documentation was just a bit out of date, and several of the links I got handed in Slack contradicted each other. Stand-ups were tough because people gave their quick summary to Clint and that was that.

And I couldn’t even access the team’s board for a couple of days.

Frustrating.

But finally, I got my access squared away. One of our DevOps guys, Steve, was great and patient at working through my access issues. Where he couldn’t directly set things up, he knew who to ask. And by Wednesday or Thursday of my first week, I was ready to do something more productive than chase down access!

Clint assigned me my first task. We had customers who were using a new brand of arc reactor management software (ARMS). I needed to add it to the list of ARMS types.

Cool.

So I dived in. I looked through the code. Yep, there were some ARMS packages in that list there. How did that affect how our system interacted with the customer? More digging. More looking. Not really clear. Finally, I asked Clint. It turned out I just needed to add that new ARMS package to the list, and that’d be it. Just add the string.

That was, again, frustrating. There was no way I could have known that. And maybe I could have asked questions ahead of time to figure that out, but until I dug in I don’t think I even had enough context to understand that there might be implications of adding a new ARMS package. I definitely didn’t have enough context to understand how adding a single string to a list that populates a drop-down could produce any value whatsoever for Marvel, LLC., or for

But after getting a few more access issues resolved, I finally, about two weeks in, got my first commit deployed.

Several weeks after I started, I got to go to my first all-engineering meeting. A lot of folks had their cameras off. There wasn’t a welcome for those of us that were new. That felt kind of sad.

I remember musing that help at Marvel, LLC., seemed to fall into one of two categories: “here’s a fish” or “here’s a fishing rod with a disassembled reel, and a map.” I don’t recall what prompted this—probably a culmination of time I’d spent tracking down access and help, and the difficulties I was having in getting to an understanding of the product and its context. But I do remember how it all felt.

Frustrating.

DC vs Marvel

Two onboarding experiences with two companies where I got to work with smart people from whom I learned a lot. Even allowing for the different company factors (e.g., DC, Inc. was much smaller than Marvel, LLC.), the two experiences were hugely different.

There are two questions I want to explore.

First, why did I feel frustrated and lonely at Marvel, LLC. even though there were people there to help—but not at DC, Inc. where I was mostly solo that first week? I think the answer may have something to do with what I worked on my first week at each.

Second, was I simply oversensitive to the Marvel, LLC. onboarding experience? How could we tell if that’s so? And if so, is there a way to construct an onboarding experience that doesn’t make Matt² grumpy, that still works for other people who might have enjoyed their Marvel, LLC. onboarding experiences?

By way of wrapping this up, I will mention that I have made a practice of taking notes during my onboarding experiences. Those initial days with fresh eyes are unusually valuable to a company or a manager. It’s easy to forget how difficult or frustrating an experience was³. Writing it down ensures the thought can be retrieved in its original form. If you’re starting with a company, or even switching roles, take notes.

At Marvel, LLC., I used my notes to offer suggestions to Tony, the CTO. I was able to share my experiences, both good and bad, and was given the project of improving the onboarding experience for future hires. Because I had notes, I was able to come up with specific items to improve.

But improvements to onboarding are a future post. This was the tale of two onboardings, and that tale has now reached its end!

1. The opening sentence of Seveneves by Neal Stephenson is “The moon blew up with no warning and for no apparent reason.” Action builds from there. [↩]
2. I gave everyone else superhero alter-ego names, so I feel like I should do the same for myself. But I won’t. Since, y’know, Matt happens to be my name and that might get confusing. [↩]
3. This quirk of memory may be responsible for the continuation of humanity, as the “let’s never ever do this again” feeling of waking up to deal with a crying baby fades into the feeling of “we can totally do that again, and y’know, I think we should!”. [↩]