Giving Juniors an Opportunity to Grow
13 July, 2021
While working at a previous company, I was managing a junior-level backend developer on a full stack team. They were very young, but hungry to grow. During one of our one-on-ones, this person expressed an interest in taking on more ownership of the projects that they were working on.
Looking objectively at our hierarchy of seniority at the time, they were very low on the totem pole, so ownership was not really anything that they were getting. The projects that interested them generally would go to a more experienced employee, and tasks would be disseminated throughout the team therein.
I took the request from this junior developer as a challenge. How could I introduce this person to more ownership and accountability, without setting them up for failure by assigning them to a task too advanced for their level of expertise? It is not responsible to give an employee like this something that encompasses too large of a scope.
I was managing a full stack project that was staffed by three engineers. Person A was the most senior member of our staff, a backend engineer leading the a full stack project involving both mobile and backend work. Person B was a senior mobile engineer, tasked with handling the mobile aspect of the project. Person C was my junior engineer, eager to excel.
Initially, Person A was the technical lead for the project, and they would be collaborating with Person B in order to define the project in the technical specification and to develop its timeline. We were going to have my junior engineer take care of the easier work to be done on the backend while my senior engineers took care of the more complex parts of the project. This plan ended up changing slightly, however.
I asked my junior developer how they felt about taking on ownership of the backend development. I warned them that they would be relying on this senior mobile developer to lead the project and the other senior back-end engineer for support; this point of contact would do what they could, but the training wheels would be off, so to speak. I encouraged my junior to take some time to immerse themselves in the domain and to get a good handle of things on their own in preparation for the endeavor.
What ended up actually happening: Person A stepped out of the picture to some extent, becoming a source of guidance and support when needed. Person B became the tech lead for the project, giving my junior-level engineer a chance to take ownership of the back-end design and development. My junior was able to step up and take ownership, which was very exciting for them.
I wanted my junior to push themselves; I didn’t want things to be too easy. I told Person A to only give guidance when necessary; wait for the junior to ask questions. I think that going through the pain of learning is vital to growing into a new role. I also made sure to clarify that too much pain may hinder progress.
We spent some time configuring this trial arrangement, and then I just let them all roll. I scheduled one-on-one sessions twice a week for the first three weeks to coach everybody through the process and to clear up any confusion. After three weeks, I was able to take a step back and watch as they all came together as a team. My junior developer was learning and getting everything that they needed.
This exercise actually turned out to be a great idea. The release of the feature went well and the experience opened a lot of doors for my junior-level developer. Mistakes were made, as always, but they saw all of their commitments through post-release and continued on that positive path forward. Everybody was suddenly seeing the new value that this person was bringing to the table.
From then on, whenever there was a big project to do in that domain, Person C became the team’s go-to trainee when more help was needed. Systems like this allowed us to invest in ourselves as a company, cultivating the talent that we already had on staff. My junior-level report finally had the ownership that they were after, as well as a renewed sense of confidence in their ability to level up and to deliver.
- You want to give people what they are looking for professionally, but you need to do so safely, in a way that will not overwhelm them in terms of skill or scale. Helping this junior developer build their sense of confidence depended on my ability to set them up for success. When people are able to overcome a challenge, you see that in the results of the project. There is a more active engagement, as opposed to somebody just doing what they’re told without giving any input.
- When setting out to do something like this for one of your own employees, the senior-level mentors that you utilize will be one of the most important factors to consider. Ideally, you want to choose somebody who is both very experienced in the domain in question, as well as somebody who also has some skin in the game. Set clear expectations with all parties involved. Explain why things are being done and your reason for doing them. This junior-level apprentice’s success becomes the success of those mentoring them. You cannot succeed as a team if this person is simply left to fend for themselves. This context allows your delegates to account for some contingency in terms of time and resources as this younger employee strengthens their understanding of the work at hand.
- As a higher-level manager, you need to be wary of spreading yourself out too thinly over time. One of your most valuable resources is the insight that your senior-level team members can provide you. Lean into the higher-level managers that you oversee. They lead these projects, so you stand to gain more information from one meeting. Sessions like these are more efficient than putting the story together piecemeal from multiple sources.
- Young people have lots of energy. Direct that energy effectively, and they may develop quickly into senior-level employees themselves. You need to wait for the right opportunity; something new being produced within the company, or another novel initiative. Connect them to leaders who will be able to provide context and support at every intersection. It takes quite a bit of planning, but the results speak for themselves.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.
Director of Product at Startup
William Bajzek, Director of Engineering at Sapphire Digital, is always keeping his eyes open for ways that he can give his team a chance to learn something new.
Director of Engineering at Sapphire Digital
Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.
Adi Purwanto Sujarwadi
VP of Product at Evermos
Neelima Annam, Sr Director Information Technology at Outmatch, recalls a time when she had to use non-conventional methods to train her team.
Sr. Director Information Technology at Outmatch HCM
Neelima Annam, Sr Director Information Technology at Outmatch, shares her insight into her growth path of evolving her management style to build trust.
Sr. Director Information Technology at Outmatch HCM
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.