Practical Junior Friendly Teams
6 min readNov 17, 2024
What is junior friendly?
Junior friendly simply means accepting a junior in the team and setting them up for success, whether fresh after studying or with a few years of experience.
Being a junior means they have little knowledge about being an employee, what teamwork looks like, how goals are set, and lack relevant functional knowledge.
That’s why they usually need to be told not only what to do, but also how to do.
In a junior friendly environment, they learn and become more and more productive, bring more and more value, need less and less support. They thrive as they meaningfully contribute and can see themselves becoming an expert in the industry.
The opposite of a junior friendly environment is intimidating, threatening, insulting, giving only negative feedback, setting unrealistic expectations and eventually making them doubt continuing in this profession.
Why junior friendly?
Go back in time — how did you start? You were junior once, and you either made it the friendly way or the hard way. Which one is more effective and pleasant?
Assuming juniors join the team, what are the benefits of being junior friendly?
For the senior members:
- With everything you learned and experienced, you’re in a great position to grow and shape the next generation
- Selfishly, when you teach, you learn or relearn yourself, deepening your expertise
- Teams that consist of only senior members might have frictions due to repeatedly opposing views and lack of will to take easy or boring tasks
For the organization:
- Team cohesion, collaboration
- Higher performance as juniors can contribute more quickly and in the right ways for the team
- Higher retention as juniors feel valued
For the junior:
- Expedited growth, broad learning, focus on the most important areas
- Incremental growth of self-esteem and self-confidence due to increased mastery and autonomy
- A positive work experience, job satisfaction, engagement and motivation
The cost of junior friendly
As always, everything is a trade-off, which needs to be considered:
- Risk of the junior not developing self-reliance and independence.
Mitigate: set expectations, start asking “What do you think we should do?” and ask them to document. - Time and thought invested into preparing, teaching and supporting.
Mitigate: keep it structured and documented, with guidelines and limits. - Risk of cuddling, resulting in slow growth, always saving them from failures or keeping an under-performer, if the manager cannot challenge or give constructive feedback when needed.
Mitigate: give timely candid feedback, set goals for the probation period. - Perception of favoritism from the manager and resentment toward the junior, friction with members who believe the only way to learn is the long and hard way.
Mitigate: explain the benefits and boundaries of the friendliness, remind them how it was for them to learn new things.
How to be junior friendly in practice
- Set realistic expectations. Match the level of the tasks to their skills and their growth plan. Be as clear as possible about what you expect from them. From being on time for meetings, telling the truth and communicating their absence in advance, to what the standards are, what skills and tasks they will have been proficient in and by when.
Asking a junior who never heard of automated tests to cover your legacy code is likely to fail as much as asking them to design the distributed architecture of the project. - Explain, verify, don’t assume — juniors don’t have rich experience by definition, they haven’t had the time to read a lot of books and experiment with many things. Make an effort to explain terminology, techniques, why things are done in a certain way.
Don’t ask a junior to change a synchronous API call to asynchronous, to use dependency injection or to fix N+1 problem without verifying they know what it means. - Set psychological safety — make it safe and encourage asking questions, suggesting ideas, admitting lack of knowledge and mistakes. This is how members learn the fastest and teams’ performance increases.
Guide them on how and when to ask — ad hoc or collect questions and ask in a scheduled daily check-in session.
Comments such as “You should know by now”, “I already explained” or “This is a stupid idea” will be counterproductive. - Inclusiveness — a culture in which all team members’ opinions can be heard, not only the manager or the most senior engineer decides what to do, when and how.
- Onboarding — give the full picture: the company, industry, domain, users, coworkers, stakeholders, ways of working, methodologies, coding standards, development process, tooling, …
Teaching only the IT or vacation policy will not set up for success. - Documentation — the tools, the product, “how to”s, public documentation, post-mortems, employee policies, architecture diagrams, team structure, etc. Make it easy for them to find relevant information, and ask them to update what is out of date.
Relying on knowledge that is only in people’s heads will make it a burden and discourage asking. - Assign a buddy — a colleague whose job is to answer all the junior’s questions in 1:1 and have check-ins.
Leaving them to wonder about things will make them feel alone and avoid asking questions they might consider too basic. - 1:1s like with every team member, to build trust and rapport.
Not having or frequently canceling signals they are not important. - Give continuous feedback, so they know what behaviors to do more of and less of.
Waiting for the official quarterly or annual performance review to give feedback is a disservice, and robs them of the chance to improve quickly. - Coaching - facilitate the process of their growth of skills. This includes guiding them on what to focus on and what resources are available, such as online courses, books and an education budget.
Expecting them to know what to work on and how is likely to yield little success. - Delegation — minor things to allow them to have some responsibility after they start feeling valuable and comfortable. Push them to take responsibilities that are a bit outside of their comfort zone, but not in the danger zone and are not crucial for the success of the team.
- Pairing - besides the obvious benefits for the team, working together with them on tasks of all types, expedites their learning of techniques, tools, the domain, and how to get stuff done.
Evaluating their work only once it’s done will probably end up in a lot of calibration and rework. - Collaboration — the team is the unit of execution, the team is the owner of its domain and the goals.
Setting up a competitive work environment will ensure not helping others. - Mentoring — the expectation from all team members to support their journey.
Members that are not supportive and not approachable slow down the growth. - Knowledge sharing — sessions about the product, frameworks, libraries, techniques, methodologies, architecture, coding katas, mobbing sessions, etc. It expedites the practical learning.
Leaving each to their own might end up in knowledge silos and a low bus factor. - Social time — whether as short as an ice-breaker before the retro, a weekly virtual coffee, team lunch or events — the unofficial time together helps build trust and rapport between the members.
- Work-life balance — juniors are often enthusiastic and excited to prove themselves. They might seriously overwork to learn, prove themselves and get things done. While it may be reasonable, when exaggerated, it will cause high stress, may lead to low self-esteem and set the unhealthy habit of overworking as the modus operandi.
- Celebrate wins — on top of positive feedback, publicly recognize achievements after verifying they are not afraid of being in the spotlight.
Not recognizing their achievements might give the feeling they underperform and all their efforts are discounted.
