Joining Alan as an Engineer

Joining Alan was a different experience to what I was used to. It took me some time to fully adapt to the written-first culture and radical transparency Alan works by.

Fortunately, the onboarding process is adapted to accommodate for these novel ways of working and helped me get up to speed.

Your first days as an engineer

You arrive with a group of newcomers from various communities (engineers, sales, support…), always on a Monday morning. My first day was mainly dedicated to setting up my laptop and checking all my accounts were in order. It’s also the occasion to present yourself on Slack and get a warm welcome from everyone. They’ll ask questions about your hobbies and possibly a picture of your cat (if applicable).

I was presented with my very own and unique onboarding todo, gathering company onboarding as well as engineer onboarding. They contained personalized cards with what I should be doing during my first two weeks: whom to meet, what to read, what to set up and when.

I also met three people who took care of me during the first months:

• my “role buddy”, a fellow engineer who sat next to me and assisted me on everything technical. They are the go-to person for any question you have about engineering. They’ll also guide you to your first tasks to implement and how.
• my “culture buddy”, someone from another community (ie: not an engineer). They will be your point of contact for everything related to the Alan way of doing things.
• my “coach”, a more senior engineer who will follow your progress and help you grow in Alan. That’s the person you’ll have regular 1:1 meetings with.

What initially surprised me the most is the sheer amount of information available. “100%” of what Alaners produce is at your fingertips. If you ever try to read every Slack channel, every comment, every written discussion you won’t be able to get anything done. One of the first things you’ll have to learn is how to organize yourself to know what to read, when, and more importantly what to not read.

Also there are no restrictions. Except for user-sensitive data, you’ll never have to ask permission to anybody to modify something or follow a time-consuming process to get access to a particular tool. This speeds up things by a large order of magnitude but can be a little bit scary at first.

Woodchucking

After my arrival, I didn’t start working in a crew (our name for product focus teams) right away.

I obviously had in-person training for every aspect of the company. Those courses are spread over the next several weeks to avoid the infamous “death by powerpoint”.

As for getting you acquainted with our tools and codebase, Alan built a process called the “woodchuck program”.

A “woodchuck” is any task that can possibly be performed by a newcomer. Any crew or community can create them: they range from bug fixes and one line improvements, to small full fledged product features. These tasks have a small scope, are well defined and have a clear referent to whom you can ask questions.

At first, my role buddy “suggested” to me some woodchuck from his crew and helped me release them. Alan expects that you’ll ship production code in your first week (and usually within your first day).

I was then able to pick woodchuck tasks from the board of any crew I wanted. It’s a great way to discover what many crews are working on. You can also get familiar with the backend and frontend code, mobile development, devops or internal tooling.

Choosing your first crew

Crews are rearranged every quarter, so you probably won’t join the crew of your role buddy or your coach. This first assignment will depend on what you want to do and of the current needs of the various crews.

You decide yourself when you feel ready to stop the woodchuck program and join a crew; your coach and role buddy will help you. By that time I had met many people and worked on different engineering problems so I had a pretty good idea of what to expect. At the end of the quarter you’ll be able to change to a new crew if you want to. And the next. And the next. You’ll never have the feeling of being “stuck” in a crew because “now you’re the expert on X”: Alan never wants you to be bored.

It can feel odd to join a company not knowing exactly which part of the product you will be working on. I found the ability to try different things and interact with various engineers very refreshing. It also helped me to create bonding relationships with people working on other crews.

After a few months, I could more easily see the “big picture” or understand how various parts of the codebase interacted.

This apprenticeship also made me want to work on different parts of the project. I now can’t wait to pick the next challenge!