Onboarding Script

This is an example of a script that we have found success with. However, you should feel free to create one that you feel comfortable with.

Each section should be copy and pasted one at a time, with headings formatted as Bold and Italic and giving the engineer ample amount of time to read through and think about the sentences they're reading. Be careful not to overwhelm them by posting too much at once.

Before you begin, be sure to prepare a dogfooding challenge and quiz for the engineer. They will be used later in this script:

  1. Quiz
  2. Dogfooding

Manager's Note:

During the example script below, we have the engineer complete a quiz and a dogfooding challenge. We consider both to be important to the onboarding process and recommend creating them before starting.

Welcome Notes

Welcome to the team! I'm ${yourName}, and I ${whatYouDo} here at MobileCoin. Let’s get you started with the onboarding process.

Please note: all time related to MobileCoin, even if it isn’t direct coding, should be logged on Upwork.

We’ll continue when you have completed the above.

Discuss Check-Ins

Great! The next thing we’ll do is have you set up a time with me for your Weekly Check-in. This is a 1 hour meeting between you and me that takes place every week. Let me go through what they're all about:

Our Check-in’s:

We use the Check-in meetings to see how engaged our engineers are.

If an engineer comes to a Check-in every week without much to discuss, I become concerned that they are not as engaged as I would like. The Check-in functions as your opportunity to speak with me about anything that is important to you. This can be about your work or questions pertaining to personal development.

I will also use Check-in’s as an opportunity to provide you with feedback. They are here to help guide you with your work at MobileCoin, and they are also interested in your overall progress as an engineer.

Every day when you sit down and do work here at MobileCoin, think about the challenges you face. Think about what you would like to see change, or what you could be doing to make things change.

In the end, the Weekly Check-in’s are only going to be as good as you can make it. You have to bring your own contributions because ultimately, they are all about you.

With that all said, does ${yourPreferredTime} work for you?

Weekly Team Meetings

These meetings take place every ${yourPreferredTime}.

Please note that these meetings are mandatory. They function as a method to get everyone on the team on the same page for the week. This can be used to pinpoint or address the previous week's pain points or successes, as well as address any areas of communication that need improvement.

Manager's Note:

The time that these meetings take place is entirely up to you. We do recommend that they take place at the beginning of the week to maximize their effectiveness.

Standuply

Manager's Note:

We have had great success with Standuply as it has allowed us to form a way for engineers to structure their day, but more importantly plan. It forces them to think in terms of input and output as a daily routine.

This functions in a different way for the manager. With Standuply we can see what they have worked on, plan to work on, if their daily plan succeeded, or if it failed and why.

The uses this tool provides is truly invaluable.

I added you to Standuply, so you’ll now get reminders for status updates each day at {$time}. You will have 15 minutes to respond, so you can choose when you submit your updates.

It's important to know what these daily Standups are used for. They are here for you to hold yourself accountable for what you plan to get done for the day.

Here is an example of the daily Standuply:

How many PRs have you approved since the last standup? 3

How many PRs have you rejected since the last standup? 1

Keeping the above in mind, what do you plan to accomplish before the next Standup? Do not include reviewing PRs as part of your answer. I will be adding tests for saving assignment HTML, then I will create the GET endpoint for getting the assignments’ files

Look at your plan from the previous standup. Did you successfully complete it? Yes

Below are some good examples of appropriate responses for "what do you plan to accomplish before the next Standup?":

"I will create a Research Summary Doc for Project XYZ"

"I will complete feature XYZ"

"I will write three tests for Bug XYZ"

Here are some bad examples:

"Will work on X"

"Working on feature XYZ"

"Researching bug XYZ"

You should actively approve and reject PRs throughout the week. If you have not approved or rejected PRs, you should note as to why on your daily Standuply Report. This explanation should be added to the daily standup's 5th question by selecting "No" and adding your reason there.

Slack Etiquette

No Private DMs Regarding Work

Using Private Messages (DMs) to talk about work

When another engineer asks for assistance, the thought “someone else will help them out, I’m too busy right now” can be prevalent. This can lead to no one answering the question, making the engineer think they need to privately message someone for assistance.

This should be avoided at all costs.

If you and another engineer are discussing a topic and are unable to come to a solution, a public conversation allows both of you to quickly include someone else. That engineer can read the previous conversation and get up to speed quickly. Public conversations can also serve as documentation. Someone searching for a term related to that conversation may find that it helps them to understand the problem they are currently facing.

Effective Communication

We are social creatures, so it makes sense that we want to make sure that there is someone to talk to before we send a post out into the oid of a channel.

ex. "Hey, has anyone encountered problem X?"

This may seem like a rather miscellaneous question, and you'd be right. What exactly is wrong with miscellaneous questions?

Answer: They waste time and space.

With miscellaneous questions, you can expect the conversation to flow like this:

[12:01] Dev 1: "Hey, has anyone encountered problem X?"

[12:03] Dev 2: "Oh yeah, that's a doozy."

[12:03] Dev 1: "How did you figure it out?"

[12:06] Dev 2: "I did fix=XYZ."

[12:08] Dev 1: "I've already tried that, didn't work."

[12:12] Dev 2: "Link me your PR"

[12:17] Dev 1: "Done"

[12:24] Dev 2: "Oh wait, your PR is for repo ABC! That's why my solution didn't work. Try fix = ABC"

[12:30] Dev 1: "You're right! That did the trick, thanks!"

That's 9 posts in a channel if they don't use threads, and over 30 minutes to solve an issue that had a quick fix.

Let's see what the conversation might look like if we cut out miscellaneous questions and instead used concise, well-thought out communication:

[12:01] Dev 1: "Hey @dev2, @dev3: I'm working on LinkToPR in Repo ABC, I've tried fix=XYZ,FIX=X. Am I approaching this the wrong way?

[12:02] Dev 3: "Did that last night, use fix=ABC"

[12:03] Dev 2: "Agree with @Dev 3. Fix=ABC is the solution."

[12:05] Dev 1: "Fix=ABC worked! Thanks!"

That took up 4 lines of code and lasted 5 minutes. Effective communication builds the team and helps the engineer learn how to communicate better.

Engineering Duties

Status & Notifications

Since we require you to be active from , please be sure to keep your status on Slack active. As any @mentions you may receive have the chance to be nullified by your "Away" status.

I would also like for you to set the notifications for this Weekly-Check-In channel to "every new message".

Always Have a Plan

When faced with a problem, most engineers will launch right into a solution. Rare is the engineer who will set down and weigh out the pros & cons of a particular solution. In doing so, they might arrive at a better solution than the one they initially came up with.

Not every task requires a plan. Fixing the margin on a button or creating a simple CRUD API endpoint do not warrant the need for a plan. Implementing a new reusable component? Plan it out. Building a major new feature for the site? Plan it out.

Self-sufficient

Even the most well-intentioned engineer has a bad day, resulting in a choice that accumulates debt at a higher interest rate than others.

You should be self-sufficient and adept at navigating existing code that you did not author. Turning to others for help is actively encouraged, but only after first trying your best to comprehend on your own first.

Incremental Development

By delivering small, incremental changes, we allow for quicker feedback.

Large parent branches that are separated from the day-to-day work of the rest of the organization can feel like a necessity when developing features that can take weeks to implement. That is, until some bug fix has been made upstream on the existing feature that is being actively worked on in a silo. It takes a diligent engineer to spot that upstream bug fix and make sure it is properly incorporated into the parent branch so that bug is not reintroduced when the new feature work is launched. When it comes time to merge that parent branch into the main branch, a nasty bug can result in reverting week's worth of work. The resulting haystack can be quite frustrating to wade through, demoralizing a team upon what was supposed to be a big launch day.

To avoid silos and maintenance nightmares, small, incremental changes are required.

Test-Driven Development

Test-Driven Development (or TDD) is essential to ensuring the quality of our code, allowing for bugs to be potentially caught during development. Both front-end and back-end code should be covered by tests. Any pull requests that do not include sufficient test coverage should be sent back to "In Progress" so that they can be corrected.

Bugs

Whenever a bug is discovered, the engineers responsible or the relevant team need to address it immediately. If you view the bug but are unable to address it yourself you should @ other devs in the bug Slack thread to get their attention.

Permissive > Prescriptive

It is not uncommon for an engineer to ask for permission to make a small change. Not used to the empowerment that comes with working at a start-up, contract workers tend to ask their managers if it's okay to use tool X. It is important for them to understand that they are empowered to make changes, and should be encouraged to discuss those changes with their team if needed.

There are exceptions of course. Can we use this plugin? You probably don't need to ask. Can we update our whole build process, causing countless man hours to be wasted on upgrading something that doesn't really need an upgrade? It's a possibility but it needs to be discussed first.

Another important lesson to learn is deciding when to discuss a small change vs simply implementing that change and submitting a pull request. 30-60 minutes on a PR might be a better use of time than the same 30-60 minutes spent discussing it on Slack. Worst case, the pull request gets denied and a small amount of time was spent on something that ultimately was not worthwhile. That is okay. It’s a fine line between being proactive and knowing when to ask for permission. Being consistent about your goals and communication will help in this area.

Dogfooding

This is where we would recommend introducing the engineer to your company's approach to dogfooding.

Manager's Note:

Consider this your chance to show the engineer what the app should look like from a customer’s perspective.

Show them what the app should look and function like. Give them an idea of how customers will navigate, message doctors, create meetings, and more.

Oftentimes this means creating a dummy account and having the engineer complete certain steps to gain an idea of the app they are working on.

This is a common onboarding tactic when bringing on new people that gets them “on the same page” as everyone else. Thus making them work towards the same goals your team has.

Required Reading

Here's a list of the articles we have our new engineers read. Please take your time to read them all and let me know when you have completed all of the below:

Quiz

You’re almost done! Taking all of the information you’ve learned above, please answer these questions:

Manager's Note:

This is where you have them fill out a form that you believe best showcases their understanding about their workspace and what is expected of them.

It can be a Google Form, Typeform, or any other form of polling that you choose to use. The length and amount of detail in this quiz is entirely up to you as well.

It is important for you to pick necessary aspects of the job that you want to be 100% clear with the employee on. This can be used as a reference later on as well.

Introduction to Team

I would like to introduce you to the team and have you give them some information about yourself. Let us know when you have completed your intro!

Get Them Started

You’re all set! Welcome to MobileCoin!

Manager's Note:

Once all of this is done, the engineer will be set up to start their first PR with you.

It is recommended that their first PR consist of a simple problem that brings them through the engineering lifecycle and gets them further acquainted with their surroundings.

After this, you will have a fully integrated engineer working on your team. Congratulations!

results matching ""

    No results matching ""