Day after day, the call goes out: "We must return to office! Remote work is harming productivity!" The claims behind this urging include one that often makes even the most determined remote worker pause and nod: juniors must have an office environment in which to learn their jobs. But is this true?
Few will dispute that junior employees are among those most negatively impacted by the remote-first model necessitated by the pandemic. After all, most productive remote workers had already forged their professional networks and built their skills in a business world that was almost entirely in-person. Entry-level employees typically lack both, and thus struggle in ways their more senior counterparts cannot comprehend. But before we declare remote-first a failed experiment and rush back to our cubicles, we need to take a hard look at why juniors struggle to network and train in a remote world.
For over a decade, I've been running one of the world's first remote software engineering internships. Our graduates have gone on to successful careers, many as senior engineers and managers, and quite a few at in-person jobs. For many, the internship was the only entry-level position they ever held.
My time as an internship manager has taught me that the answers to the problems juniors face in a remote environment are more nuanced than merely restoring in-person interaction.
Key 1: Communicate Deliberately
In an office setting, juniors absorb information through observation. So-called "fifth man" assignments provide opportunities to sit in on work sessions and see how more senior employees handle different situations. This is an appealing arrangement to employers because it costs very little, and the other employees seldom need to do more than answer an occasional question. Sometimes, the observing junior may even make a valuable contribution!
...intense isolation can become a real problem in remote-first work, especially for juniors. The solution here is to deliberately create regular opportunities for interaction.
In a remote-first environment, opportunities for this sort of passive training-by-osmosis technique are virtually nonexistent. Most work is done asynchronously, or else through ad hoc interactions like Slack Huddles or JetBrains Code With Me sessions. A person can easily spend an entire week without hearing another human voice, at least outside daily meetings. As a result, intense isolation can become a real problem in remote-first work, especially for juniors.
The solution here is to deliberately create regular opportunities for interaction. (Note: this is not justification to book more meetings.) Here are a few techniques I've seen first hand over the years, including some I've implemented in the internship program:
Regular collaborative sessions, such as mandatory pair and mob programming. Woody Zuill has an excellent talk on how powerful daily mob programming is, and why your team should try it. I can personally vouch for its effectiveness, both for productivity and leveling up everyone's skills. Even on the most dysfunctional team I ever worked on (as a mere developer), it was a potent technique.
Tools like Gather Town to encourage more ad hoc group interaction. One team I led used this tool daily for nearly a year, and the frequency and quality of our interactions were on par with an in-person office.
"Shared space" sessions, where everyone joins a video call while doing quiet solo work. Similar to Gather Town, this increases natural opportunities for observation and interaction.
Daily shared work journals. When the internship program went international, it became difficult to schedule times for everyone to be present concurrently. Mandating daily work journaling (e.g. as a replacement for stand-up), and commenting on each other's journals, strengthened work relationships and created countless mentorship and co-learning opportunities.
If you're using Agile in any fashion, then Sprint Retrospectives are your best tool to figure out what collaboration patterns are working for your team, and which are not. Adjust accordingly, but never make regular collaboration optional. I recommend that between 30% and 50% of the work week should involve some form of active or passive collaboration (such as a "shared space" session).
Juniors in any field possess a special skill: they don't know the "right" way to do things, so they're more likely than a senior to invent novel solutions and spot subtle errors.
Within this context, ensure your staff is including the juniors! Team members should offer to let them observe or participate in collaborative sessions whenever practical. One may think that pair programming with a junior developer sounds like an awful waste of time, but I have lost track of the number of times my interns have taught me something or caught some error or edge case I'd completely overlooked. Juniors in any field possess a special skill: they don't know the "right" way to do things, so they're more likely than a senior to invent novel solutions and spot subtle errors.
Key 2: Prepare Your Staff
Bringing juniors onto a team should never be taken lightly. You are asking the rest of your team members to add "mentorship" to their effective job description, and as with any expansion of responsibilities, you must communicate expectations, requirements, and policies. This is doubly true in a virtual environment, where anything short of deliberate engagement results in isolation.
Let the mentee devise their own solutions....Only step in when they ask you to, or when they're about to walk off a steep cliff. It is easier for someone to dig themselves out of a hole they dug for themselves, rather than a hole you dug for them.
There are a few principles I recommend for anyone in a mentorship role, whether formal or informal:
Ask more questions than you give answers. Try to lead the mentee to discover the answer themselves.
Demonstrate more than explain.
Be honest with your shortcomings. Tell the mentee about the time you took down the production server! Normalize making, owning, and fixing mistakes.
Offer to research with the mentee, even if you know the answer. No one is born knowing how to properly use Google, ChatGPT, or Stack Overflow.
When you explain something, always have the mentee explain it back to you.
Let the mentee devise their own solutions, even if they're different from yours. Only step in when they ask you to, or when they're about to walk off a steep cliff (e.g. delete the production server, cause the project to overrun deadline, etc.) It is easier for someone to dig themselves out of a hole they dug for themselves, rather than a hole you dug for them.
On the whole, one always learns more from making and fixing their own mistakes than by any other means.
Key 3: Onboard Well
Naturally, none of my interns were ready for this kind of responsibility on day one. Every junior starts the same way: excited, overwhelmed, and with rare exception, scared stiff.
Excellent documenation is essential for a smooth onboarding process, and this goes for all employees! Every team should have a routinely maintained step-by-step guide to setting up and getting started with work. For developers, this guide should take anyone from zero to merging code that meets the team's standards and definition of done. Similarly, all standards, policies, procedures, and workflows should be documented in a standardized location. When this documentation is in place, onboarding occurs within 1-2 days; without it, it can take weeks before a new team member is independently delivering value.
(Pro tip: ask each onboarding employee to immediately report any errors or confusion to someone who can correct the documentation. Onboarding documentation should be self-contained and repeatable for juniors and seniors alike; no prior knowledge or external guidance should be needed, except where explicitly hyperlinked.)
For junior developers, the first task I assign is usually a review of a more senior developer's code....all the interns who started with code review were competent in the language within a month.
On day one, a junior should be paired with a mentor. In most cases, their first face-to-face interaction with that mentor should be the same day. However, juniors should also meet their mentor's manager, and should know how to contact them, just in case there are conflicts or concerns.
There are two things you do not want to do on the first week: do NOT leave them to their own devices, and do NOT assign them career training materials. You are running a business, not a school. There is probably some good training material you should provide later -- in the internship, I had two books that were required reading -- but you want to get them doing actual work as soon as possible. Make time later for "continuous career training," and ensure it's something you provide to your whole team, not just your juniors.
For junior developers, the first task I assign is usually a review of a more senior developer's code. I instruct juniors to work through it slowly, looking up any syntax or pattern that is unfamiliar, and asking the code author to explain anything they still don't understand. I am always amazed at the effect this simple task has on a junior's learning path. Most interns came into the internship program with no knowledge of C++, our primary language, but all the interns who started with code review were competent in the language within a month.
Key 4: Check In Regularly
Juniors in particular must never be left to guide themselves. Even the most self-motivated entry-level worker lacks the expertise to recognize flaws and inefficiencies in their techniques in a reasonable time frame.
...research is a treacherous rabbit hole, especially for juniors. Encourage them to timebox their research within an hour or less before asking for help.
At minimum, every junior should have an assigned mentor, with whom they meet at least once a week over video chat or face-to-face. I emphasize one-on-one, as it is often difficult to admit to gaps in knowledge or skill in front of a group, even peers.
It is crucial that the mentor asks plenty of open-ended questions. In particular, I recommend the following:
What went well this week?
What challenges did you face?
What have you learned this week?
What are you trying to solve right now?
How can I/we best support you this coming week?
In general, juniors will seldom voluntarily admit to not understanding something. Nearly every intern I've ever trained has felt compelled to exhaust all possible avenues of self-guided research and experimentation, up to the point of completing entire Udemy courses, before asking for help.
While it's an important skill to find one's own answers, research is a treacherous rabbit hole, especially for juniors. Encourage them to timebox their research within an hour or less -- I usually suggest 30 minutes -- before asking someone for help.
Finally, don't assume that juniors are getting everything they need out of their working relationship with their mentor. The manager should also check in with the junior and mentor separately, at least once a month. Find out how the junior is feeling about their overall experience with their mentor and team, and if it aligns with their needs and career goals. Determine if the mentor has identified any opportunities for growth, or any potential challenges or concerns.
Key 5: Assign Real Responsibility
One mistake I see many organizations make with their interns and entry-level employees is to assign them tasks with little or no importance to the project. Juniors aren't stupid: they know when they are expected to fail, and will respond with timidity, thereby capping their professional growth.
I had to entrust senior-level tasks to the interns. What took me by surprise was that, with rare exception, interns rose to the occasion and completed the work to the standards I'd expect from experienced developers.
In running the internship program, my development teams consisted largely or entirely of interns. This forced me into a position some would consider ill-advised: I had to entrust senior-level tasks to the interns. What took me by surprise was that, with rare exception, interns rose to the occasion and completed the work to the standards I'd expect from experienced developers. Yes, I had to provide a bit more initial guidance than I might with a senior developer, but the results were nearly always superb. I had interns designing and implementing critical pieces of software architecture, building and maintaining DevOps pipelines, debugging esoteric bugs, and even leading project teams. These weren't all college seniors and graduates either; we had a mix of students, boot camp grads, self-taught hobbyists, and second-career learners from all over the world.
In assigning real responsibility to juniors, ensure mentors check in regularly to spot problems and ensure they don't veer off the path. Just as important, continually gauge the junior's interests and confidence level. If they are bored with a task, encourage them to finish it to their best ability anyway (because not all tasks at work are fun!), and then reevaluate what sorts of tasks to assign them. This is a prime season in any professional's career to discover their strengths and weaknesses. By encouraging this experimentation and exploration, you will both give and receive the most value.
Things To Watch Out For
In all the time I've spent training interns and mentoring developers, I've learned three warning signs that an individual will not do well professionally without intervention.
Juniors who repeatedly refuse to seek assistance when stuck, or who actively avoid collaboration, virtually never succeed. You must never allow collaboration to be optional!
1. Lack of attention to detail.
This can take the form of skimming instead of reading, a pattern of sloppy mistakes, or routine disregard of policies, procedures, standards, or workflows.
Mentors should explain the importance of slowing down and paying attention. Encourage note-taking and effective reading and listening strategies as appropriate.
However, be mindful of neurodiversity here; if a junior expresses routine difficulties with focus or attention, encourage them to seek out appropriate resources and professional guidance. Accessibility and Disability Employee Resource Groups are crucial here!
2. Poor time and priority management.
Watch out for juniors who are frequently late for, missing, or "forgetting" appointments and deadlines, even with excuses. Notice when they repeatedly disregard communicated priorities, such as completing low-priority tasks over high-priority ones. Inversely, notice when they are working too much, failing to take breaks, or are hyperfocusing for hours on end.
In this situation, mentors should introduce time and task organization techniques, such as Pomodoro Technique, Bullet Journaling, and Getting Things Done. Once again, be mindful of neurodiversity here.
3. Isolation, or "Lone-Wolfing" (and Psychological Safety).
Juniors who repeatedly refuse to seek assistance when stuck, or who actively avoid collaboration, virtually never succeed. This is where it is absolutely essential that mentors maintain regular lines of communication with their mentees, and teams deliberately include juniors in their day-to-day work. You must never allow collaboration to be optional!
Address problems at the scope they occur.
However, if a junior is avoiding interaction, don't assume they're doing so out of a desire to go it alone. Psychological safety is absolutely essential! You must carefully monitor your team's communication patterns, and swiftly address any forms of harassment, discrimination, destructive criticism, and hazing. Juniors should never have to "earn their place", regardless of who they are or where they come from. They are a full-fledged member of the team from day one, and must be treated as such.
If you notice anyone, junior or otherwise, is avoiding collaboration or communication, have a gentle one-on-one conversation with them. Draw out their concerns and fears, and do your best to address them.
To that aim, address problems at the scope they occur. If an employee makes inappropriate jokes in team meetings, call them to account in the same team meetings. If someone is being harassed on a Slack channel, address the harassment on the Slack channel. If discriminatory remarks are made in private, address it in private (with or without the victim present, as appropriate.) This is important for three reasons:
It tells the victim that their safety is a priority.
It tells observers that the problem behavior is not acceptable; you are both discouraging similar behavior and empowering others to intervene in future situations.
It puts pressure on the offender not to repeat the offense, by sending a clear message that they will not be protected from the consequences.
In addition to psychological safety, you must consider if there are neurodiversity-related issues leading the junior to isolate. If this is the case, you should consult with them and HR to determine if any accomodations can be put into place to address the issue.
Once you've addressed or ruled out any of the above, if the junior continues to isolate, you may need to utilize a formal Performance Improvement Plan to tackle the problem.
Conclusion
Juniors can make incredible additions to your team. They often draw out the best from other team members, and their eagerness and inexperience helps keep everyone out of the dreadful rut of "we've always done it this way."
On a remote-first team, juniors additionally expose flaws in communication and collaboration patterns. When their success is made a priority, the entire team will discover new and better ways of working remotely.
In this new era, we have an incredible opportunity to rethink how we approach work. Today's juniors are tomorrow's seniors. The patterns we establish now will forever change the professional world. The companies that adapt to these new challenges will be the winners, attracting the next crop of talent entering the workforce.
Top comments (4)
Great points, and generally consistent with my own experiences. I would like to point out, at my current employer, we do all pair programming all day, and I think it's a little too much. (Conveniently for me I do tend to get a couple hours to myself at the end of the day just from being in a different time zone from the majority of the team, at least.)
Your note about putting a junior on a team involving an addition of "mentorship" to the team's responsibilities is spot on. The last project I worked on, we had two very fresh juniors added to the team that had come out of the client's internal "train non-engineers to be SEs" program. They were great people, dedicated and smart, but also a significant drain on team resources and the more time we took to mentor them properly, the less we could deliver new features. That's fine when accounted for, but something to watch out for. Also, spending the entire day mentoring was....not exactly what I signed up for, which lead to not insignificant burnout when that was what I did most of every day for months.
Spending part of the day pair or mob programming is definitely useful for juniors (and everyone), but I also want to point out that the greatest delivery benefits (especially short term) of pair programming as a constant practice are seen between people of similar skill levels.
Finally, to your point about things to watch out for - the client had promoted an individual as a team lead who had very poor attention to detail - constant misspellings in comments and variable names, failure to even bother to set up auto-formatting tools (and no sense of janky whitespace), so on. This was a detriment to the entire team as other team members tended to feel discouraged and demoralized from actually caring as well. I'm not sure that the client leadership ever fully understood the negative impact this SE had on the team.
Woot! Great to see a fresh post from ya Jason. Your writing is full of great advice and as engaging as always.
Wonderful!!! Lot of tips, thanks for sharing.
So, true. I have seen in office. We do set people for success or failure.