This content originally appeared on DEV Community and was authored by Aviv Kotek
Ramping up quickly matters
Assuming an engineer's median tenure is 2-2.5 years, ramping up quickly matters.
I believe a new dev should be delivering value after 4 weeks of intensive, planned onboarding.
Consider an alternative, where value is delivered after six months. A five-month delay accounts for 20% loss of an employee's budget. fun numbers
Following below ideas, you can create your own team-specific onboarding plan:
Methodology:
Managers responsibility: ramping up is 100% managers job. Free up your time and take it seriously.
Task oriented: create a Story ticket, with relevant sub-tasks owned by dev, committed to current Sprint.
Hands-on: onboarding includes code and production tasks from the very beginning (think 'bootcamp'). We'll start with a code-task to align standards and conventions and move quickly to production tasks.
Prod tasks can be either:
{bug, refactor, small-feature, infra imprv}.Duration: 4x weeks, 2w for logistics, dev-task and learning. another 2w for prod tasks.
Identify early low performers. bad hires happen, don't drag this too long and try to find red flags from the very begining.
Identify early technical weakness, areas of improvements and adjust the onboarding plan accordingly ("New hire never queried a DB").
Ceremonies alignment: this is the time to align on: time estimations, technical design, code review and Daily. New hire report's progress on Daily.
Conventions alignment: pushes code into a sample repository, following existing standards and validated by code review.
1x Buddy / Context: define a Senior developer that will follow new hire. Every question should go to him, we'd like to minimize overall teams context-switch. This is also a chance to let "potential leaders" an option to mentor others.
Self led: it is expected from hire to own and run plan independently. Should not drain other peoples time.
Brook's law: do not engage with critical prod tasks at the beginning.
Get to know your colleagues: engage with existing team members via learning sessions, where team members teach you a technical related subject and relationships are built ("Backend Services Overview").
Local environment: invest time installing local env early on. Verify you have a simple "how-to" document.
Sanity checks: schedule check-ins to verify things are as expected and verify:
{Do you want to pair more? Do you want more alone time? Are there particular areas you need more guidance in?}.Retrospective: conduct retrospective meeting, collect data, feedback and adjust plan accordingly.
Serves a dual purpose: an opportunity to demonstrate new hire that they have joined a professional environment.
"Most bootcamp graduates agree that the most valuable part of bootcamp is the tasks they are assigned.
Engineers have real work assigned to them the first time they open their laptops and many push code to the live site within their first week."
(Boz, 2009)
Following these ideas, you can build your own onboarding plan, heres how we do it in Semperis:
This content originally appeared on DEV Community and was authored by Aviv Kotek
Aviv Kotek | Sciencx (2024-06-29T09:40:48+00:00) Onboarding new devs. Retrieved from https://www.scien.cx/2024/06/29/onboarding-new-devs/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.