Any organizational leader is always challenged by the ability to quickly get new engineers active and effective as they join the company. This is commonly called “onboarding”. Common approaches include
- Boot Camps similar to Facebook,
- Intern style mini-projects
- The dreaded fix-a-few-bugs in the first week
- The sink or swim, here is your desk, hit the ground running
All of these approaches (except the last one) attempt to
- Familiarize a developer with the code base
- Do generally low-risk changes and get the code into mainline or production
- Start to understand the systems and tools that the team uses
Generally, the stated intent of on-boarding an engineer is to bring them up to speed and be productive. In this post, I’d like to turn this on it’s head and ask the industry to not look at the onboarding process as a way to get an engineer started, but rather a way that the existing engineering team showcases the code, the architecture, the behavioral norms and the vibe of the engineering team.
I’ll lean on the analogy of an rich elderly aunt visiting from out of town throughout this post. The onboarding process is like that awkward first few minutes where you walk through the house showing the washroom, kitchen, where they are sleeping and other items that are needed to make the stay welcoming. However that five minute tour is usually at the end of a few days of frantic cleaning, scrubbing, removing trash, setting rules for how the kids should act, and so on. After all your familial reputation is on the line here. Who want’s an awkward Thanksgiving or Christmas where there are the little comments, the glances and whispering from the aunt who has formed her opinion of how you operate as a family.
When a new engineer arrives at a company, the deepest scrubbing we usually do is to make sure their desk is clean and the computer is there. It leads to an awkward recruiting moments when the reputation of the company is passed on to other engineers as the new engineer is asked ‘How’s the new Job’. In the same way the elderly aunt is associated, but not vested with you. So is the the new employee who hasn’t quite felt part of the team.
Turning the onboarding process on it’s head also has some material impact on the way the engineering team see’s itself. When you have a visiting relative, you want to show that you are a the good part of the family, and have your things in order. Use the onboarding experience as a way to ensure that the team presents a real demonstration of how the team is awesome. You can’t fake awesome for very long.
Make your leaders of the organization accountable for how the team is presented to the new hire. Make those leaders ensure that the 2-4 week honeymoon period for the new hire sets the basis for a long term relationship. The discussion shouldn’t be whether an engineer is now productive for the company, it should be whether the company has made an engineer productive.
That inversion goes a long way to extend that honeymoon from a few weeks to a few year. That inversion helps engender an organization that fosters growth and development during an engineer’s tenure. That inversion changes the way the organizational leaders look at how they run the organization.
Make Your Leaders Accountable for Onboarding
The critical part of this inverted view of onboarding is making the leaders of your engineering team responsible and accountable for the onboarding of the engineering team. Some indicators of issues to consider when examining the onboarding process.
- Can the new engineer checkout and build with no major hiccups? Typically there is a verbal tradition that carries engineers from the written references to being productive. (“Oh yeah, you need to this or that, we should update that”).
- Does the new engineer need to talk to other engineers for a basic bootstrap of their environment?
- Does the new engineer need things explained on a whiteboard?
Realistically, the new engineer doesn’t have the ability to influence how quickly they come up to speed. There will be an intrinsic ability that the new hire carries, but the largest influence of how the new hire onboards is carried by the organization.
By making the hiring manager and their lead engineers responsible for the effectiveness of the new engineer, it forces introspection on the team about how they manage their development how much of the way the team operates is transparent, captured, and communicable and how much is opaque and a form of verbal tradition.
Some measures that I push my teams to meet for a new dev are:
- After the initial orientation and first login, be able to sync the code and start a build within 1 hour. (This forces the hiring manager to ensure the permission groups, environments and access is all done before the hire starts.)
- Have the engineer be involved in a code review within the first day, but before their first change. (This sets the bar for how the code reviews operate and the expected conduct for the engineers on the team).
- Have a problem or proving task able to be resolved and pushed to a staging environment, device, into a build within the first day. (This drives an understanding of the way the development goes from the developer to production).
- Have a debrief after the first day and the first week about the questions, points of confusion, suggestions and best practices that the new hire misses. (This helps drive introspection for the team for the next round of hires).
Equivalence to Technical Debt
A lot of these negative indicators and the difficulty in achieving the measures are driven by the technical debt that an organization is carrying either consciously or subconsciously. Finding opportunities to spot the technical debt that is causing friction within an organization are golden.
Technical debt in a development team is most visible to a new hire. They walk headlong into it with open eyes and an inquiring mind.
Helping the Future Self
The future self concept covers the lack of familiarity that an engineer will have with some code or a system that you are currently working at some point in the future when you need to go back to it. Over time, poorly written code – even written by yourself, becomes that code written by the clueless engineer a few years back.
Technical debt is usually correlated with old crappy code. However while the engineers are writing the code, there is not the assumption that the code that is going in is crappy.
A new engineer being onboarded to a new system is in exactly the same place that a future self or a new transfer into the team will be seeing. They don’t have the history and so it will always be more jarring to them. Future selves and new transfers will have enough history that they will orient themselves back to familiarity very quickly. Warts and all.
Learn From the New Engineer’s Honeymoon Period
Engineering leaders, should look closely at the questions, feedback, and interactions that a new hire has with their new code, systems, and team. They don’t have the history or familiarity with the code that helps them skip the opaque or confusing bits of how you do development. This will help not only with onboarding new hires, but also the engineer’s future selves, and people switching into the team.
Those first few weeks of a new engineer are extremely valuable, use it as a barometer for how effectively the team is managing technical debt and creating maintainable code and systems.
Don’t squander those first few weeks. Also, keep your house in a state that your elderly aunt would like.
As always, vehemently opposed positions are encouraged in the comments, you can also connect with me on twitter @tippettm, connect with me on LinkedIn via matthewtippett, and finally +Matthew Tippett on google+. You can also follow me on Quora, or simply follow this blog.