Stormtroopers for Startups
As a teacher-turned programmer, I have a few recommendations to help startups support successful mentorship while minimizing wasted resources. This is the first of three articles about mentorship, cloaked in the garb of The Sith Lord. If you’re in a position to oversee the work between a mentor and junior, this one’s for you. It touches on the dangers and pitfalls of power.
A long time ago, in a galaxy far, far away, a fiscal meeting was held wherein several disturbing truths came to light, worst of all the fact that the only thing hindering the rise of the dark side was a labour shortage.
Darth Vader found the situation extremely annoying after all the work they’d put into stealing the Jedi’s clone army. Having remotely choke-slammed several of his secretaries to no avail, he secluded himself until he found a solution. What happened next changed the course of history: He decided to recruit new members and implement a two-part training system consisting of an intense training bootcamp followed by an apprenticeship. While no one ever marvelled at his army’s skill, he certainly managed to fill out the ranks.
Several millennia later in this galaxy, the startup industry finds itself in the same understaffed situation, and we’ve turned to Vader’s pragmatic solution for help. Dev bootcamps are recruiting hordes of four-eyed hopefuls and are thereby revolutionizing the web development industry. Because of the growing importance of mentorship, I think it’s important that we do it better. What can you do as a manager?
“Powerful you have become, the dark side I sense in you.”
Let’s say that the time has come to expand your reach. Your company requires a diversity of dev tasks and it’s appropriate to have a variety of skill levels on your team. You have enough resources that you can afford to take the calculated risk of training a junior. If all goes well, you might be able to trade six months of your strongest dev’s productivity for a new trooper.
In order to minimize disruption to your team, the first thing I’d recommend is to talk to them and assess their bandwidth before bringing on a junior. It’s going to be a lot of work, and it’s going to affect them most. Frankly, a lot of companies are surprised by how much a junior doesn’t know. An entry-level developer isn’t an independent agent who can hit the ground running. Their bootcamp or degree provides a foundation, but the onus of the practical apprenticeship is on you and your team. It’s not ideal, but we need more people than we have, so we all have to take some of the collective pain of developing the workforce our industry needs. Your competitors are going through the same thing.
“You will find only what you bring in.”
If you and your team agree that you have the resources to take on a junior, the next thing to do is take a moment to consider your expectations for both the junior and the mentor, and whether they’re realistic.
Both the mentor and the learner are going to have growing to do. Being a great programmer doesn’t necessarily mean that you’re a great teacher. It’s almost like you have two learners on your hands: an experienced programmer working on their teaching skills, and a person working on their programming skills. What can you do to make sure that the arrangement is as mutually beneficial and productive as possible?
Set up a positive and motivating environment and be patient. It will take some time before the junior is really productive, and at first they will actually have a negative value, since they will require hours of the mentor’s time in order to push even menial work. Being angry at the junior for being incompetent won’t make them perform better and it’s important that the mentor knows this too. Since choking people with your mind isn’t really a thing, it’s better to control people using positive motivation and compassionate treatment. It sucks, but it’s true.
“Looking? Found someone you have, eh?”
Who do you hire and appoint?
First, I’d recommend not hiring too many juniors at once, assigning just one mentor to a junior at a time. The mentor will have a better understanding of the junior’s weaknesses and the junior won’t have to deal with conflicting opinions. Exposure to different ideas is useful later, but problematic early on.
Learning relies on good communication and understanding, not on grasping the toughest algorithms on the planet. If you agree with this, it might change what you look for in a junior. Because there isn’t a significant technical difference between entry-level programmers, it could be better to preference personal qualities over technical prowess. Some traits that make someone a good student are self-awareness, resiliency, and confidence. They help a person shut up and listen, survive tough feedback, and engage in the team.
The personal qualities of the mentor are also important. One of my best teaching mentors taught me that connection proceeds learning, and experience has confirmed that a good connection between mentor and learner facilitates superior communication and skill acquisition. A learner who feels comfortable and motivated is far more likely to succeed. Choose a mentor who is happy to mentor a junior, but is also comfortable setting limits on their availability so they don’t go insane. They need self-awareness, empathy, and a sense of humour. It will come in handy the first five times they explain the same thing, but after that they need beer.
Another important thing to consider is the skill level of the mentor. Someone who knows marginally more than your intern is not ideal. Imagine you had to send a member of your team to save someone who was drowning in water instead of code. You would choose a strong swimmer or risk exacerbating the tragedy. That doesn’t mean you send Michael Phelps, but don’t send the guy with the arm floaties. I would also suggest that the mentor’s age be closer to 40 than 20. Even better if they’ve parented a child, done hard time, or worked on the tar sands. Life makes you a better person.
“The fear of loss is a path to the Dark Side.”
By the time you’ve filled those roles and put your people in a positive and motivating context, most of your work has been done and your power is poised to grow. It’s time to decide what you will do with that power.
You may have noticed that I lured you here under the premise of expanding a dark and all-powerful army, only to pepper my meagre offerings with teachings from Grand Master Yoda. I did this because those who crave power need to be careful, and there is a major problem in our industry that I want to address, because it can be very destructive.
It is this: CONSTANTLY WORKING A DEVELOPER 12 HOURS A DAY IS NOT A GOOD IDEA. There is a reason why our society underwent a Humanist revolution and established an eight-hour work day as the norm. Sitting in a chair for twelve hours a day cripples your body and makes it almost impossible to live a balanced life. Your employees want and deserve better. Their job is to write things that can work around the clock, not to be those things.
It’s also far better for you to employ people who live balanced lives. Having a balanced life implies that someone is more likely to understand the real-world problem your business solves, and that they have experience with social relationships. This helps them manage themselves effectively, understand what you want, and make useable software. If you have a bunch of socially-retarded masochists writing the behaviour your business runs on, managing them will be a constant problem, your app will offer a bad user experience, and everyone will hate you.
“You must unlearn what you have learned.”
Some people seem to think that juniors are an exception when it comes to their need to live balanced lives. Our industry likes to put people through some kind of overtime-hazing period. If it’s about hazing, fine, but know that excessive hours will screw their lives up without guaranteeing proportional skill acquisition. For a new developer, coding all day is the equivalent of writing the LSAT all day. After eight hours, anything they do manage to barf into their text editor is unlikely to work. Of course you want to see high engagement, and it’s reasonable to work overtime when the team has a big deliverable, but making a habit of burning your people out is ineffective.
“To be Jedi is to face the truth, and choose. Give off light, or darkness, Padawan. Be a candle, or the night.”
If you’re constantly working anyone in your company 12–18 hours a day and you think they’re fine, why not ask them when they last exercised, what their hobbies are, how their health is, and what their partner is like? Those things are really, really important, and if the way they’re working makes it impossible to have those things, then I urge you to change that.
Because they are more than just developers, mentors need even more consideration. You may need to adjust the mentor’s dev workload for their first few months in the role. This will make mentoring more appealing to the best people on your team because it will be different work, not more work, and because they’ll be set up for success. If you can’t afford to significantly reduce their dev tasks, you can always get creative and reduce them slightly while lightening their mentoring work. This can be accomplished by assigning the intern minor css fixes a few days a week or giving the mentor a day to work remotely so they get a break from their padawan.
If you set things up right, you can take more of a backseat role and pass things on to the mentor with regular check-ins with both them and the junior.
I will conclude by encouraging you to use your command of The Force for good and not for evil, but you must choose your own path. You have the power to choose whether or not to expand our workforce while elevating it with your vision and humanity. May the force be with you!
Click here for part two of this series, which is for mentors.
