There is a moment in each leader’s career when they need to take care of a team consisting of inexperienced people. It can be an overwhelming task in the beginning, and not every leader will be able to cope with it. Many leaders, especially those who have only been working with experienced staff before, might become demotivated while working with junior colleagues. They may simply get annoyed and lose their cool pretty quickly.
Focus on guidance
You cannot expect the same behavior and maturity from junior engineers as you could from an expert with 10 years of experience. When you deal with a team of junior engineers, you need to focus on guidance and coaching more. There are many things which you normally take for granted and wouldn’t even spend a minute on while working with an experienced team, but that you will need to explain to a junior team thoroughly.
A lot of leaders treat junior teams as if they were actually experienced, and that’s completely wrong. When they are faced with problems, they tend to perform a few ad-hoc interventions and get confused if it doesn’t help. In the end, they’ve got the ultimate excuse. It’s easy and convenient to say that the team has failed due to inexperienced staff. Of course, leadership has nothing to do with it. It’s their fault!
A junior team doesn’t necessarily equal bad performance. When they are guided by a right leader, they can even outperform more experienced members under poor leadership. That’s why you shouldn’t worry too much if you get such an opportunity as a leader. And believe me, working only with experienced team members is not easy either.
If a 7-person team consists mainly of architects and senior developers, the probability that a conflict will occur increases. It’s because, apart from having broad knowledge, they will more likely have different visions. And it’s not an easy job to satisfy 7 experts by having one short discussion. Sometimes negotiations and discussions can last for days or even weeks without an actionable outcome. But that’s a topic for another article. Now, let’s get back to junior teams.
Analyze the skills
The first thing a leader of a junior team should do is to figure out what kind of skills there already are in the group. Identifying each individual’s strengths and weaknesses is a fundamental part of your job. And don’t assume that your junior team members don’t have any skills at all. Being inexperienced in Java or .NET isn’t associated with other important skills, like database, graphic design, social media, communication or presentation. Those can also be valuable and they are not so easy to find in the job market.
Be sure to list all the skills which encompass the values of your organization. From technical skills, which are important from the craftsmanship perspective, to soft-skills. You can start with topics and subject matters, tools and technologies, processes and practices. If you want, you can also put the interests of your colleagues, which might be useful for the company.
I’ve met a few software engineers who were also marketing geeks, and thanks to such a hobby, they could provide so much value to the company. Apart from having their regular tasks, they were given a chance to help the company in marketing activities and managing social media. It was a win-win situation. They could improve their marketing skills during business hours, and the company was supported in the marketing area by passionate people. You never know what kind of expertise your colleagues can provide until you ask them.
For each piece of the topics, decide on competency level needs and identify individual contributions. It’s not something that you should prepare by yourself, though. It can be a group activity, giving you and your teammates an opportunity to self-organize through open communication.
Another approach is to have a one-on-one session with each of your colleagues. It can sometimes be helpful in situations where you deal with shy people who don’t like to share too much in front of others. It’s up to you to decide how to fill the matrix, but make sure it represents reality.
The main idea behind the competence matrix is to identify the gaps in your team’s expertise. It helps you to understand what competences you need to improve in order to build a cross-skilled team, and how to prepare a proper strategy for your team’s development.
Different types of juniors
Right after your competence matrix is filled out, you’ll notice what you need to focus on particularly, and where the largest gaps in your team are. Based on that you can prepare a personalized development plan for each of your junior colleagues.
Typically, you can find three main categories where the gap appears: technology & tools, process, and behavior. It’s crucial to identify them in order to adjust the proper coaching and leadership activities.
Lack of technical skills
First and foremost, being inexperienced is of course related to technical skills and tools. If your team consists of people who just graduated from college, they probably lack the hard skillsets of the industry. It can be the knowledge of programming languages, architecture, and coding practices. Those gaps are important, because without such knowledge, they will not be able to make tradeoffs and good decisions. It’ll be hard for them to predict all the consequences of their decisions. How can you develop such skills? It’s a matter of technical training and workshops.
As a leader, you need to make sure that your “technical junior” builds up his technical skills and becomes conscious about the work he does. Such workshops should be based on real-life examples. Forget about artificial and abstract activities. Instead, focus on the real work. For instance, if they develop online store applications, you should make sure that topics and problems presented during the workshop relate to this domain.
Moreover, the best way to make sure the knowledge stays in their heads is to make this process cyclical. Don’t focus on one-time events. Consider a series of smaller workshops and trainings. They don’t need to take a few days or a week.
Once when I was working in a company as a software engineer, our leader was organizing coding kata exercises for every junior engineer. Kata is originally a training method in which successful combat techniques are being preserved and passed on. The idea is to practice so often that your movements become perfect and you execute them without thought or hesitation. And that company had the same idea. We were meeting every day at 9:00 a.m. in the same room starting our day by having a 15-minute exercise, which was meant to teach us the best coding practices, e.g. writing unit tests, keeping code clean and foreseeing potential complexities. It worked pretty well. It was our daily routine and our coding skills became much more fluent after only a couple of those sessions.
Lack of process skills
Another type of junior colleagues you can have on your team are those who don’t follow organizational processes. For you as an experienced leader, it seems pretty obvious to follow all the rules. But for your colleague, who just graduated from college, it can be cumbersome to understand why he or she needs to follow additional rules. They are happy enough when something they built is actually working. What’s the point of all those company practices and rules?
In the programming world, you can see software engineers not following coding standards and good practices, such as writing unit tests or hardcoding values. Sometimes, they don’t understand how to assign tasks to themselves or how to follow project methodologies, e.g. Agile or Scrum. Although they can be a breath of fresh air to the team, they need to conform to common rules.
Your role as a leader is to ask them why they don’t follow the process. You need to understand their point of view. Actually, maybe they’ll provide some interesting observations. Once you get it, provide a broader context for all those rules that they don’t seem to obey. It’s your duty to establish a clear process, boundaries, and even penalties if necessary. I know it sounds pretty harsh, but sometimes it’s the only way to make the ecosystem work. Process makes sense if everyone follows it. Otherwise, there is no point in making an effort to create one.
Lack of behavior skills
That’s the most tricky part. I can tell you from my own experience that technology and tools are the easiest aspects to work on. It’s a matter of hours spent on technical workshops. But when it comes to behavior it’s solely a cultural thing.
For instance, your teammate can be a victim of the Dunning-Kruger effect. He or she can lack the self-awareness to recognize the flaws. You provide such a person with constructive feedback, work on the flaws, but nothing seems to be improving. The person doesn’t seem to understand the problem and becomes offensive. It’s a problem of pride and ego, which prevents your colleague from making progress.
The other example is a toxic person who criticizes others and turns each discussion into a heated debate. It’s hard to focus on solving a real problem when a person puts too much emotion into the conversation.
The best you can do is to talk to those people and understand why they behave like that. Maybe there are some hidden reasons for it. Apart from pointing out the bad behavior and preparing coaching sessions, I suggest you focus on their outcome. Sooner or later, toxic behavior results in poor performance and poor quality of the work. You should monitor such behavior and make your junior colleagues accountable for their goals. If you notice that there is a correlation between poor behavior and poor outcome, you’ll have an ultimate argument for your discussion with a toxic colleague. Numbers speak for themselves.
But that of course doesn’t give you a 100% guarantee that it will result in any behavioral changes. Changing culture is definitely a long-term task and you may not be able to improve it anyway. In such cases, it’s more efficient to cut your losses and find a person more suitable to the culture of your team.
Don’t micromanage
People can learn from their successes and failures, but they barely learn when you give them what they need on a platter. One of the biggest mistakes leaders make is trying to control everything. If you plan for them, solve their problems, and make decisions for them, they will get lazy. They won’t need to put any effort into their work, because they’ll know that in the end someone else is going to help them or even do it all for them.
I know it’s tempting to solve someone’s problem, because it speeds up the execution of a task drastically. Of course, as an experienced leader, you’re probably able to solve an obvious problem much quicker than your junior colleague. But if you’re the one always doing it, they’ll never get better. Speeding up a single task can result in slowing down the whole learning process.
Give them feedback
Without clear feedback, junior colleagues can get lost. You need to remember that they may not be aware of what they are doing right or wrong sometimes. That’s why they need constant supervision and input about what is great and what still needs to be improved. It seems pretty obvious, but I often see leaders neglecting this part, and the result is always the same. A leader gets annoyed by juniors not doing their job right (these are often process-related aspects), and junior colleagues are not aware of what they do wrong. As a consequence, the leader announces he’s not satisfied with the work after a few months and makes a decision to replace a particular junior, who inevitably gets fired or moved to another department. But by then it’s already too late for any corrections.
Give them voice
Last but not least, give your inexperienced colleagues the ability to share opinions. Whether this is a formal meeting or an informal get-together, ask them regularly about their ideas, insights, and comments. There is no better way to motivate junior engineers than to make them feel an important part of a team. It shows that you care about their voice and it lets them develop their skills even faster. What’s more, it introduces a positive culture of an empowered team, in which every person is accountable for their work.