Apogee Suite: AI-Powered Legal Document Research Platform
By VICTOR ANJOS
Ever since the days when I ran Viafoura’s Engineering department right through to the present day, I have fought to really mechanize the way in which I onboard new staff. The common pain I had at startups was the catch-22 that all startup founders notice:
That’s right, regardless of your processes, your team and whether you are using internal recruiters, HR, hired recruiters, Indeed, Angel List, GlassDoor, etc… there is a MASSIVE PRODUCTIVITY HIT when hiring people at a small company.
Before we get to the best way to fix your onboarding process, let’s start with the standard tips and tricks that I’ve utilized over the years in my many roles hiring the best of the best and unearthing high potential junior talent.
Show them the ropes
The “sink-or-swim” onboarding technique is one many new developers face – and it can be incredibly stressful. It’s worth investing the time into adequately explaining your startup’s processes, code, and culture to a new hire before tossing him or her in the deep end.
I have previously used onboarding talks and codelabs – documents designed to help new developers understand my teams’ core abstractions – to introduce junior developers to the company.
Spending 2 hours per day for a month (40 hours) mentoring or training a new hire represents less than 2% of the total time the new hire will spend working his or her first year, it is much higher impact to invest those 40 hours training someone to increase his or her productivity and learning rate than it would be for to spend those 40 hours working on the product.
Teach to learn the ropes
One of the most powerful ways to learn is by teaching others, which is why if you have the budget it’s extremely effective to hire more than one entry level hire at a time. They can bounce ideas off each other, ask questions they may be too embarrassed to ask senior developers, and teach each other what they’re learning.
An alternative is to implement a system in which your most recent hires are in charge of teaching your newest hires. I recommend having the last person who was taught do the teaching for new hires and refine the process and documentation. This works because the information is still fresh in his or her mind – and it will help to cement it even more to explain it to someone else.
One way of doing that is through a collaborative onboarding document, where you can encourage new team members to add to it as they go. This will help them learn, and organically grow your onboarding process.
The buddy or mentor system (pay it forward)
Whether it’s a senior developer acting in a mentorship role or another junior developer who’s acting as a peer buddy, assigning a specific person to help show the ropes to your new hire can significantly reduce his or her stress levels. Along with providing answers to common questions, an assigned mentor can provide an employee-centric view of the company’s culture.
Even more helpfully, mentors can be useful in bringing new hires up to speed on your company’s processes and help them get more comfortable with the code. The opportunity to look over the shoulder of someone with more experience is incredibly valuable for junior developers.
In order to get the most use out of a mentorship or buddy system, it’s important to give it structure. Implement a regular meeting time or pairing schedule, such as an hour every morning with check ins at the end of the day.
Set (realistic and SMART) expectations
It’s helpful to set goals for your new hires so you can both keep track of how much progress is being made. Shipping a feature, getting comfortable with the code, or mastering new skills are all good milestones to put on the list. I am a HUGE advocate of having any new tech staff commit to our code base (the production version) in the first week, even if it’s an innocuous change.
Developing a master onboarding checklist is a great way to do this. With weekly and monthly goals of how much progress the new hire has been expected to make, he or she can be aware of how far along in the process they are, and know up front what you’re expecting in terms of growth and productivity.
However you do it, it’s important to set realistic expectations in your milestones, and provide opportunities for revisiting and feedback along the way.
Implement one-on-one’s (1:1), reviews and goal checks
Once you have expectations in place, make sure you have a regular system of code reviews and goal checks in place. Regular code reviews are important to engineers of all levels, but they’re especially important near the beginning of a new hire’s career, when you need to catch mistakes before they become bad habits. When offering criticism, be sure to keep the focus of the critique on the code, rather than the developer.
Use these check in sessions not just to see how your junior developer is doing, but to get feedback about how the onboarding process is going, as well. Ask where they’re struggling, what they’re finding the most helpful, and how they think the process could improve. Seeking out this feedback will help you plan for when your next junior developer is hired.
Encourage experimentation and mistakes
For a entry level hire to succeed, you need to set up an environment that promotes growth and – counterintuitively – encourages failure. A tolerance for risk and willingness to explore big ideas is extremely valuable in a startup, and so much innovation is stifled when new hires are instilled with a fear of failure.
Give new junior hires (especially those in data science) something to be responsible for, and allow them the independence of potentially failing at it. One of the biggest boons to hiring a Junior staff member is that you have access to new ways of looking at things – don’t squander that or shut it down in favor of the predominant opinions at your company.
Environment and team specific tips
Environment Setup
Each tech team should have a standardized way to set up their local development environment and workflow procedures. This includes:
- Recommended IDEs
- Third-party software used by the company (when possible, accounts in these systems should have been created before the developer’s first day)
- Where credentials for shared organization accounts can be found (these credentials should never be stored in plaintext, anywhere, ever.)
- How to pull code from version control
- Everything that’s needed to run relevant projects locally and push changes to version control
High-Level Overview of Project Architecture
Generate visuals of how all moving parts of their project(s) work together. This should include clients, servers, databases, and third-party systems with descriptions of their purpose and how data flows between them.
Resources for Languages, Frameworks, and Tools
This should be a list of technical documentation, blog posts, and tutorials that will help the developer fill in the gaps on all of the languages, frameworks, and tools they will be expected to use. Explain specifically how each tool will fit into their daily workflow. This should also include documentation on internal tools such as build scripts the developer will use.
Coding Standards and Values
This isn’t only useful for onboarding. All developers should have a set of standards and values to which they code. If this is documented outside of the context of the onboarding documentation, simply include a link to it in the onboarding documentation. This is also a good place to discuss performance goals and expectations for developers.
Technical Processes
This is where the code review, sprint planning, and issue handling processes should be documented. Include sprint length, when and how stories are created, and how stories move through their lifecycle.
Company Jargon
Think of this section as a dictionary of domain- and company-specific terms that may not be well-known to outsiders. This is one of those sections that experienced developers may have trouble comprehensively documenting since many terms and acronyms become taken for granted. Encourage the newcomer to add missing terms when they come across them.
Team Dynamics
Briefly describe how their team is laid out and who would be best to talk to for specific types of questions. Also define or link to the code of conduct and ethics the developer should adhere to.
Organizational Structures
This section should define how the company is laid out from a high level. Describe the various teams/projects, what role they play in the company, and how they’re connected. Lay out the best way for the developer to interact with these teams.
Encourage the new developer to update this documentation as they see fit! New developers often see holes in documentation that more experienced developers don’t. This gives the developer the opportunity to make an impact right away, improve the experience for future developers, and solidify what they’ve learned.
Pair Programming
Set aside a block each day for the new developer to pair program with a random teammate. This ties into mentorship, but gives the developer the opportunity to form relationships with the entire team, learn the codebase, and begin contributing immediately.
So what do you do when all signs point to having to go to University to gain any sort of advantage? Unfortunately it’s the current state of affairs that most employers will not hire you unless you have a degree for even junior or starting jobs. Once you have that degree, coming to a Last Mile Finishing School, with 1000ml being the only one worldwide, is the only way forward to gaining the practical knowledge and experience that will jumpstart your career.
Check out our next dates below for our upcoming courses, we’d love to have you there.