March 3, 2016

The 48-hour rule means that anyone who joins a new project or the company needs to deliver something within that time frame. What they deliver is different based on the role, but the idea is the same: they need to do something productive in 48 hours after they join the team.

For a developer it’s simple: they need to provide a Pull Request (PR) in two days time. A designer might need to share a design artifact or provide a modification to an existing mockup or wireframe. It can be more difficult to find the right task for administrative staff, but some examples would be: a marketing person posting their first tweet, a sales person logging their first call.

Find a small and productive task they’ll be expected to do regularly and set the expectation that it needs to be completed in 48 hours. Once they deliver, our first step is to give feedback on the process and take a moment to confirm that it was done correctly and that their work is up to our expectations.

It’s an aggressive timeline but it tackles the four biggest problems we’ve had in the past with onboarding:

  1. Inclusion: They go from feeling like an outsider to knowing they are part of the team. Getting over that initial emotional hump can be challenging. Once they’ve experienced the process of working with other team members, everything is less scary, and communication lines are open.

  2. Verification: It helps us look at our onboarding process. If someone new doesn’t have the correct access to tools or knowledge for their job, they can’t be expected to deliver. If we can bring attention to gaps in our process, we can make them successful. It also provides a quick opportunity for review, feedback, and analyzing any potential red flags.

  3. Attention: It takes targeted attention to make the new hire successful. Other team members are required to be available to the new team member in order to provide important information or guide them through processes. While it may be more disruptive at first, the new person quickly becomes productive and a trusted member of the team.

  4. Red flags: Sometimes despite our best efforts, a new team member or contractor isn’t the right fit. Maybe we didn’t communicate our needs well enough, or perhaps there is a skillset or cultural mismatch. Since we ask the new team member to deliver right away we see potential problems quickly.

Finding the right task and reviewing its output is the secret sauce that makes this process successful. When selecting the task it needs to be as real as possible and should require them to work closely with another team member to get it done. It’s not enough just to assign a ticket to a new developer; they need a senior developer to select – or at times simply make up – a task that is doable within such a condensed timeframe. When reviewing the task, it’s important that both their peers and their managers provide insight and feedback.

Writing this blog post spurred a new checklist of things we should also keep an eye on. We realized that while being successful in checking their code, we had been inconsistent in checking if they had logged their time correctly!

Onboarding isn’t always easy, but we’ve found that this process forces us to focus, sets a clear goal for everyone, and highlights potential problems quickly.

See Mike Minecki's profile
Mike Minecki
March 3, 2016

Posted in

Mike Minecki is a developer who dabbles in management at Four Kitchens.

Comments