The rule of two - how to grow your development team

Introduction 

Summary 

"Two, there should be. No more, no less. One to embody power, the other to crave it." Darth Bane  

I enjoy the Star Wars series - I am not a fan though. I like especially the story hidden in books and Wikipedia pages you can crawl while browsing random topics on the web. One of such subjects was the rule of two that got my eyes open. 

So the rule of two states that there should always be two dark siths, the master and an apprentice. Let us dodge the risky bits of this rule - with the full commitment and killing at the end of the path, and we have something handy, we can use in IT. 

In this article, I will try to defend two statements. 

• A Junior should always have a Senior for support so that he can grow and benefit the most from it. 
• A Junior should always be in the same office as his mentor. 

Who do we have in a team? 

Firstly, let us try to put some basic understanding into our discussion, what do I mean when I say Junior, Senior or Regular. 

I am a fan of simplifications - they are not solving all of the issues you may have in your team and life. However, they are helping out in solving the majority of the problems. In this article, I will not create a solution that fits it all. What is even more critical my definitions most likely will not match yours. 

I will try to provide you with my point of view that I hope we can discuss in the comment section. 

I believe that in a team, we can identify three types of seniority: 

JUNIOR*/**: 

• A person with at least one year of experience, not able to be a single developer on a project.
• A person that requires support and mentoring by Senior developer.
• A person that is not capable of identifying the optimisation and simplification of the tasks he/she is performing daily.
• A person that is dependant on senior team members to organise training and growth.
• A person that requires maximum introduction period when joining a company - average three months.

REGULAR*: 

• A person with more than two years of experience, capable of handling a project alone - but with some oversee from the senior. 
• A person that will benefit from the support and mentoring by Senior developer.
• A person that is not capable of identifying the optimisation and simplification of the tasks he/she is performing daily.
• A person that can identify the growth and training path that are interesting for him/her but requires senior to help with the final decision on them.
• A person that requires an introduction period when joining the company - average a month.

SENIOR*: 

• A person with more than four years of experience in at least three companies, capable of handling a project alone - without oversee.
• A person that requires no additional mentoring nor support in his/her daily tasks.
• A person that is capable of identifying the optimisation and simplification of the tasks he/she is performing daily.
•  A person with a clear goal for his/her growth and future paths.
• A person that requires minimal to none introduction period when joining a company to be able to handle the technical aspects of the problems.
• In short, a person that has enough experience in projects/companies that he can find himself fast in the new environment and fix problems based on his experience.

*Important: to be junior/regular/senior, you must fill in all of the requirements. You may have more experience in years, but you will not be yet on the level of senior. 

** Junior - I assume that a one year of experience is needed in this role, as Junior is not an entry-level position. I find trainee as the first step into an IT position, and I am not providing any comments about that level as it much depends on the school/training/etc. 

The first complication - not all seniors are mentor material. 

A senior, as is stated before, is a technical engineer capable of solving problems and identify paths solo, they do not need help, support, nor oversee. That's the perfect employee. 

In my career, I have met many of them - some extremely technical driven, with the need to learn new technology, attending conferences and sharing their technical knowledge. Some more focused on people, being able to help juniors and regulars in their growth. 

Hence I believe the seniors split into two categories: 

Mentor 

• A person that prefers to help grow the team rather than focus on the technical aspects. 

"Code Person"

• A person that prefers to focus on technical aspects rather than having any interaction with the team. 

Balancing 

My rules of thumb are: 

• I do not hire Juniors and Regulars before the core team is there, and initial processes are in place (code reviews, integrations, best practices).
• I hire Juniors if I have a Senior with Mentor skills ready to support them (1 to 1) in the initial phase of the team growth.
• I do not hire Juniors remotely.

Let me clarify my thought process behind every single one of them. 

"I do not hire Juniors and Regulars before the core team is there and initial processes are in place (code reviews, integrations, best practices)" 

For the majority of my career, I worked as a firefighter. The companies hired me to fix their problems - from senior developers leaving so that only Juniors were left in the team, through issues with the communication between the business and the tech teams. 

I learned that companies tend to have a smooth start with a significant number of Junior/Regular developers without a core team of Seniors in place. That approach caused a lot of delayed problems that were waiting to happen. 

Creating the first system setup that the team will be working on is one of the hardest tasks there is. It must be created by the senior members that have experience and seen what not to do. Having Juniors without knowledge of the best practice, the technology and the area of expertise you are working in can only cost you time and money. 

Seniors know what can happen in the next few weeks, months, hence they can future proof the systems and way of working from day one. 

"I hire Juniors if I have a Senior with Mentor skills ready to support them (1 to 1) in the initial phase of the team growth." 

No matter how smart and talented the Junior person is - it is always required to provide him with mentoring. Seniors that spend years in development knows how to communicate within the systems, how to create a future proof code, and what tools to use. A talented person, when left alone, will most likely go into "bad habits" that will cause delays and problems - not only in the product but also in the career of this person. The rule of two applied in this situation is a game-changer.

From my experience - within weeks, I was able to observe changes in the behaviour of a Junior I assigned with a good mentor.

• The person was surer of his skills - there was no more asking for acceptance on every decision. He started to suggests tools and frameworks.
• The code quality - the commits were happening regularly (daily) and pair programming gave him a lot of best practice to use in day to day work.
• He learns to ask questions - before he was working on a task for weeks, reading through the materials, finding potential issues and then starting to implement the code. Now he asked for suggestions at first and went with them while working on the subject. When he saw a problem - he was asking his mentor for help or tips where to search for answers.  
• His morales went sky high. He was demotivated and not happy with the role he had. The moment his mentor was there to help him, he was able to bloom, his mood changed. No more mister lousy mood, no more demotivation and watching kittens on youtube. 

In addition to that, the senior will be able to help optimise the work of the junior. Reduce the waste of not needed tasks from testing a method that should not be tested, automating a job that should not be automated. 

Senior will cause the junior to grow faster and with better morale than Junior could ever do by him/her-self. 

In my jobs, I have seen developers that got lost in their tasks and were not growing for months, if not years. They were left alone, without mentoring, without one on ones to discuss their personal growth and what future do they see in front of them. Bringing them back from this state requires time and dedication. What is most important, it requires an experienced professional to help them find the paths they want to go - a Senior. 

"I do not hire Juniors remotely." 

Remote work is not for everyone. For people that are about to start their adventure in the wild and weird IT world, starting from a remote position is a terrible idea. 

Juniors tend to work on the tasks without asking for help - reaching out to someone who is sitting next to you is more natural than reaching out to a remote person. 

Juniors tend not to ask and perform what is precisely in the tasks - when some of the tasks must be clarified. 

Juniors tend to get demotivated very fast. Without seeing them live, it is hard to notice the moment when they feel lost and are about to put their resignation. 

I want to add here one more important statement - an office full of Juniors, working together is still a remote position. You must have a senior mentor in the office space. 

Summary 

If you want to have a healthy and high performing team - apply the rule of two. Make sure that your junior dev always has a dedicated senior to support and help him/her in the path. 

Not all seniors fit the role of being a mentor - some of them are focused only on the code. If you push them too hard for the mentoring, you will lose the junior, the senior and the team.