Today I Learned - Rocky Kev

TIL blogpost - training new hires

POSTED ON:

TAGS: retrospective blog training newhire

See the post here: https://dev.to/rockykev/5-principles-i-followed-to-onboard-new-devs-and-keep-my-sanity-a-retrospect-38i7

It's officially been more than a month since new hires joined my team, and I'm proud to say they've been pretty successfully onboarded.

A few months ago, I shifted from Wizbang Codemonkey to Lead Cat Wrangler (non-official titles obviously). My team went from six devs to thirteen in less than a year. And I would be in charge of managing a brand new team, as WELL as all the new hires. The Peter Principle is always a concern. (tl;dr - you get promoted up and up until you fail.)

The business went, "Like your new team? Btw, here are 4 new hires. A junior, 2 mid-levels, and a senior. Okay byeeeeeee!"

How does this feel? Jim Gaffigan said it best.

Imagine you're drowning and someone hands you a baby

It took me a while to see this perspective. As a developer, in a nutshell - our job is to solve problems, but with code. We create a set of processes (a system) and run down the list. We pivot as you discover new problems. We keep working until the hit the finish line.

4 new hires at multiple levels of experience? This is just a new problem! Life is defined by the challenges you face. And I got this! 💪

This post will cover the 5 Principles I followed. I hope it's educational. And if 10... 20... 100 devs are thrown at me, this process continues to scale.

What do new hires think about?

Tech interviews are a 💩-show. So no surprise that new hires have a lot of unknowns. For example: Where do I go to get questions answered? Who is this person? What is this tech stack? What is this in-house term? Am I doing this right?

I wrote the full list in my post: What New Hires think about

As a Lead Cat Wrangler and a person in power (I can choose the toppings for the lunch pizza!) - do I continue contributing to the 'Sink-or-Swim' methodology that plagues many companies in the tech industry?

Or do I continue expanding on the dope culture that I want through onboarding, nurturing, and growth?

The Principles of managing new hires successfully

In the book "Principles", the author Ray Dalio, lays down a framework based on the unique company culture he developed while running Bridgewater Associates.

I like the term "Principles". These aren't facts or laws. They're systems that with practice, can lead to success. They might require some rejiggering from company to company. But they can fit into any training system. For example, the burpee is considered one of the best exercises to incorporate. Use it separately, put it in a routine, or remix it into some P90x, and it still works!

This post is a retrospect of the principles I followed to achieve the following:

Sarah Scribble's webcomic - internal screaming
Via Sarah Andersen

I'm fortunate enough to have a background in a lot of different companies/onboarding styles, and working in the online education space. So these principles come from theories in higher education, executive coaching, and personal development.

Principle 1: Eliminate Bottlenecks, Including You

As Wizbang Codemonkey, I was thrown into the sun and told to come back with fire. (Call me Prometheus because I bring back the 🔥🔥🔥)

As a new Lead Cat Wrangler, I can't solve problems, manage every new problem, AND teach new hires. The industry is paved with the bones of burned-out developers who think only they can solve everything.

I had to trust people to solve problems without me.

You might say, "But only I can solve that problem!"

Why is that?

To successfully cat wrangle, I need to create processes where I can offload work quickly and trust that the developer in charge has everything they need to close that loop.

Sakichi Toyoda, the founder of Toyota Motor Company and the father of Japanese Industrialization, created the 5 Whys system for Root Cause Analysis. You keep asking 'why' the problem even occurred.

If I'm the only one who can solve a specific problem, then what needs to happen where I'm not the bottleneck?

As a dev example: if you modify one data point, and it creates side effects somewhere else? Your system is too tightly coupled! If I get sick for two days, I should not crash the system.

One solution is to provide enough documentation and code examples to get progress going. (Check out Principle 3 & 4)

Other times, the solution is to isolate the hard parts. Break tickets into pieces - some for new hires, and some for specialists.

Additionally, trust goes both ways. Code may not be how you would have solved it. But then you're being a dependency again, which is a recipe for disaster. Perfect is the enemy of the good. (And you can ALWAYS make refactor tickets to clean things up in the future and make it part of your todos. Check out How to convince your boss to refactor.)

FURTHER READING

Principles 2: Organize or Die ☠️

The rules of Maker Time Vs Manager Time are pretty simple. Managers do work by going into meetings. Makers need uninterrupted time to focus. A quick "hey you busy?" can cost a developer 23 minutes and 15 seconds just to get back to where they left off (But whos counting amirite?)

maker vs manager
(image via https://blog.doist.com/makers-schedule-remote-work/)

As Wizbang Codemonkey, I can do long uninterrupted periods to focus on solving a technical issue.

As a new Lead Cat Wrangler, I get emails and DMs from project managers, all day ev'ry day.

Looks like Maker Time no longer apply to me. :-(

I approached this by:

  1. Still have a maker mindset. I still timebox. Nobody talks to me during these hours.
  2. Dedicated times for support. Treat it like college Open Office hours. I don't respond immediately unless I have to.
  3. Relying on checklists. Remember when ego-centric surgeons refused to use checklists, but the ones that did reduced death by 40%?
  4. Never trusting my memory. Everything becomes a note to review or a to-do to take action on. What gets written gets done.

As new business expectations occurred, I moved my calendar around.

As the new hires needed less support, I decreased my 'helping' time.

As new patterns arose, I updated my checklist.

If I ever dropped the ball, I make a mini-retrospective of why that happened and generate plans to mitigate that, and focus on continuous improvement.

This system isn't perfect. It continues to evolve.

FURTHER READING

Principle 3: Provide many mechanisms for growth

Everyone learns differently. It's why we have so many different teaching styles.

My team of devs are big on being learners. It's why I encourage my team to buy courses and dedicate time to studying at least once a month. For the managers who don't dedicate resources to studying: What if we train them and they leave? What if you don't and they stayed?

Empowerment through learning and growth

The 4 new hires are: a junior, 2 mid-levels, and a senior.

Imagine being in a classroom teaching Lego crafting of different skillsets.

In other words, skill level affects how you teach new hires. In education, academic boredom or over-complexity can lead to bad learning outcomes. This leads to a Goldilocks principle of "just right". But "just right" doesn't scale!

The added confusion:
In the web dev industry, I have met a lot of devs with a decade in the industry, but 1-year of experience 10 times. You know, the ones who built websites since the late 2000s but still use floats. The ones who never went deep in their architecture and still zip files as source control. The ones who gave my company bad reviews on Glassdoor because they refused to continue their education and Bootcamp students have more modern development skills than they do. And no IM NOT BITTER THANKS FOR ASKING.

Additionally - job titles such as junior, mid-level, and senior are kinda meaningless to training.

In the book Pragmatic Programmers, the authors Andrew Hunt and David Thomas reuse the Dreyfus Model for how developers at different stages of their skillset prefer to learn.

Stage 1 - Novices:

ACTION: Novices need recipes.

Tell them how to do things. Novices are very concerned about succeeding. They don't want to learn everything, they want to accomplish their immediate goal.

Stage 2 - Advanced Beginners:

ACTION: Advanced beginners don't want the big picture.

They have some confidence to do things on their own and can start using the advice in the correct context. But they don't want lengthy theories or be spoon-fed the basics again.

The Dreyfus Model (Via ResearchGate)

Stage 3 - Competents:

ACTION: Competents can troubleshoot.

They can troubleshoot problems on their own, and figure out solutions to modern problems. They are more deliberate about their planning. They're seen as 'having initiative' and 'being resourceful', and can mentor earlier stages without pulling bandwidth from experts.

Stage 4 - Proficients:

ACTION: Proficient practitioners can self-correct.

They need the big picture and will seek out and understand the entire framework. They read case studies/projects/patterns and can learn effectively from history, even if they didn't participate in it firsthand. They are very frustrated by oversimplified information.

They know how to use maxims: "Test everything that can possibly break."

Novices see this as a recipe and go, "What do I test? All the setters/getters? All the return statements?" and test everything. Proficient practitioners know to only test the core components that can cause an issue.

Stage 5 - Expert:

ACTION: Experts work from intuition.

They are the primary source of information. They write articles and books. They can diagram an application and go a mile deep into its architecture. Statistically speaking, roughly 1-5% of the population.

Using that framework, our tasks are written in a way where tickets are grouped into one of those categories. It allows us to provide meaningful work during the different stages of learning.

Collaborative learning and growth

Be mindful. Be empathetic. Remember their learning style. Have an open-door policy to allow them to ask questions, no matter how dumb it sounds.

Mathematically, 10,000 people hears about that new thing every day

For learning to scale, my team has these support systems.

Support System 1: We have chat channels specifically for asking questions. Even the more experienced devs ask questions, to facilitate an environment where we're all growing.

Support System 2: We have a collective knowledge base that anyone can edit.

Support System 3: We modify learning based on the needs of the new hire.

No one-size-fits-all. And there are different modes of learning depending on the task.

For example, using myself:
With design work, pseudocode all the way! But please let me shadow you when we're doing backend database work. And just give me documentation if I'm working on APIs. DIfferent modes for different tasks.

Support System 4: We spend a lot of time course-correcting

At the end of the day -- everything ends up in Code Review.

There's ego in coding. Not everyone takes feedback well at all. New hires are often following the patterns they had in their prior life and in unfamiliar territory, and defend themselves of why they chose that and why you're wrong.

At my company, we have the luxury of time. New hires get used to LONG code review times. Some PRs can sit in code review for a week. It's a point of frustration for new hires who come from website firms where you can quick-and-dirty !important everything and ship that code.

Not here! We will take the time to do it right. And we'll be extra supportive and polite about it. (And if the ticket is time-sensitive, is it a good ticket for new hires?)

FURTHER READING

Principle 4: Providing Doable work

One of the fears of new hires is if they're doing something correctly. That paralysis slows down growth and makes PRs take 300% longer.

And if they aren't doing it correctly, the new hire's confidence is shattered! They feel miserable. They feel insecure. Imposter syndrome creeps, and they go into The Valley of Despair.

Emotional Cycle of Change, the Valley of Despair
Image via TBD-stategies

Creating "Doable work" means the following:

Tagging tasks as "Good First Issue"

One solution that the Open source community created is tagging tickets as Good First Issue. The issue isn't easy. But it's a simple task to allow someone new to be able to learn the system, the culture, and the feedback.

In these specially tagged tickets, the scope is well defined, and there's also a history of success. Included in the task are completed PRs that do the same/something similar to reference for help. A new hire can review the PR and look at the feedback and comments, and attempt to understand how and why.

I also encourage more seasoned developers to LOOK and tag opportunities that can be good for first-timers. Great developers know when to solve a problem themselves vs allowing others to shine!

Overall, these Good First Issue tickets give new hires small wins. And small wins make big wins.

Buffet-style selection for picking tasks

The common methodology at workplaces is to micro-manage your new hires until they conform and become a goopy gray matter meet your definition of success. You let them do some shadowing, force them into meetings and peer coding, and ask them questions like "Do you know how to copy/paste?" to "How can we use prototypical inheritance instead of creating thousands of functions?".

Not wanting to deal with that micro-management noise... my team elected to treat our tickets 'buffet-style'.

Overall, we provide dozens of tickets up for grabs.

If the mid-levels want to tackle novice tickets? Sure! If the junior wants to take complex tickets, I'll back them up, and give them an out if it's too much pressure.

Concerned that the higher role devs will take novice tickets ? You shouldn't be! The goal isn't to complete the ticket -- it's to get comfortable in the company. Just like in Final Fantasy, we need to get to 100% before we can use our Limit Breaks/Overdrives.

New tasks that have never been done before? The solution: Create a safe sandbox, but with restrictions. Maybe the task needs to be broken into multiple tiers (some novice, some competent, some expert-level tickets) and you handle the complex ones. The tickets are still clearly defined, there's a scope to stay within, and define restrictions to avoid going too deep into the rabbit hole.

Note: restrictions do create stress. But stress isn't the root of evil. There's good stress and bad stress. Avoiding stress is a bit like helicopter parenting - it can cause more damage then it saves.

FURTHER READING

Principle 5: Frequent Check-ins

(Note: This is the Principle I personally need the most work on. I'm data-driven, and would prefer to throw technology like 15Five at this. But I can't.)

All developers need to be empowered that we trust their ideas and feel ownership of the code. But developers are also very good at getting into rabbit holes and can't see the forest from the trees.

Checking in too frequently and they won't feel confident in solving problems (Breaking Principle 1). If you let them go on their own too long, they can go into a spiral (breaking Principle 4)

Unfortunately, I don't have a direct answer here.

I have multiple touch-points to see how the new hire is doing.

We work remotely. Which means I can't just hover over their shoulder.

I constantly test my check-in methods. My check-ins are now a bit focused, with a lot of vagueness (oxymoron!). I ask these basic questions to break the ice:

  1. How is everything? -> Some share their day. Others share their immediate feelings.
  2. What are you blocked by? -> They share what they're working on. Or if they're stuck, they try to explain how.
  3. How can I help? -> This simple powerful phrase empowers the new hire to think through exactly what they need.

FURTHER READING

These Principles aren't just for new hires

Although these principles were geared toward scaling onboarding new hires, I discovered they made me a better developer/leader.

Principle 1: Eliminate bottlenecks, including you has allowed me to identify what's important to me and find as many ways to remove myself from being a dependency.

Principle 2: Organize or die forced me to choose my time wisely. Burnout is a real thing.

Principle 3: Provide many mechanisms for growth made me think about my learning styles. I'm figuring this out as a cat wrangler! I went through my own Valley of Despair, and have climbed out of it.

Principle 4: Providing Doable work forced me to think about clear expectations and scope in words. I messed up a LOT on this task, and my support team continued providing feedback.

Principle 5: Frequent Check-ins elevated me out of a 'thinking about myself' to a 'think about the people who need me'.

As developers, we're here to solve problems using systems and patterns.

And scaling new hires is just another problem to solve.

Related TILs

Tagged: retrospective

TIL blogpost - training new hires

A few months ago, I shifted from Wizbang Codemonkey to Lead Cat Wrangler (non-official titles obviously). My team went from six devs to thirteen in less than a year. And I would be in charge of managing a brand new team, as WELL as all the new hires. The Peter Principle is always a concern.

TIL blogpost - training new hires

A few months ago, I shifted from Wizbang Codemonkey to Lead Cat Wrangler (non-official titles obviously). My team went from six devs to thirteen in less than a year. And I would be in charge of managing a brand new team, as WELL as all the new hires. The Peter Principle is always a concern.

TIL blogpost - training new hires

A few months ago, I shifted from Wizbang Codemonkey to Lead Cat Wrangler (non-official titles obviously). My team went from six devs to thirteen in less than a year. And I would be in charge of managing a brand new team, as WELL as all the new hires. The Peter Principle is always a concern.