Employment of software developers is expected to grow 24 percent from 2016 to 2026 in the US, much faster than the average for all professions. Stack Overflow estimates that a full third of professional developers are new to the calling, having learned to code in the last five years. Businesses looking to recruit fresh talent need to have a program for getting new talent on board and up-to-speed quickly. In a previous post about preparing developers, we looked at how deliberate, up-front training can cultivate confidence and get new hires generating value in record time.

The CareerStart program we launched this year has become a case-in-point. We hired six awesome early-career developers, put them through our intensive CareerStart training program, and then placed them onto client projects. We don’t just leave these to fend for themselves—the relationships we’ve developed in training are sustained. Working with CareerStarter Saif Momin on a recent project with an aggressive timeline proved that active listening and trust-building throughout a project makes the whole team faster.

Remove the experience bias

Many teams make the same mistake with their new developers: they give them the easy tasks while tenured developers work heads-down on the hard parts. We can do better. By listening for clues that a developer is ready for more responsibility, you can ratchet up their skills while balancing the workload across a team. You’ll eliminate the bottlenecks you’ve been creating for yourself by maximizing the potential of teammates, regardless of their years-of-experience.

We had partnered with a client to create a performance test suite for their system. The work consisted of writing out test cases—scripts of what actions a user could take, so that those scripts could be run over and over again simultaneously. The list of test cases to write was quite extensive, and we had an aggressive, fixed delivery date to fit them in.

Our two-person team was tasked with laying down the infrastructure in the first week. The first few test cases we wrote confirmed our assumption that we needed a larger team to meet the deadline, so we rolled Saif onto the project. Had we not prepared him ahead of time, this would have been a naive move: An unprepared developer is likely to make a project like this drag.

Look for readiness signals

To reach the deadline, everyone needed to be empowered to operate at their best. Rather than blindly assigning tasks and playing “Work Item Tetris” against a calendar, I frankly needed to shut up and listen. I let Saif’s work tell me when it was time for more responsibilities.

At first, I assigned him some of the simpler tasks, ones that could be performed with relative ease by imitating the work of our more-seasoned teammate. Focusing on the easier work for the first few test cases let Saif move along the learning curve smoothly, still making progress on the massive to-do list.

As he worked quickly through his first tasks, Saif started showing signs that he was ready for more responsibility. He was keeping a close eye on the work that the rest of the team was developing, actively taking part in code review and design discussions—he was already looking at the big picture.

Turn responsibilities into learning opportunities

We made it official, giving him code review responsibilities that led to a great opportunity to put his training on merges and rebases into practice. When a teammate needs to work on the same files as you, you either merge their work into yours, or else you rebase your work atop theirs. These are two important tools for a developer to have in his or her tool belt—and to know how to use.

During the early work, we drilled on the merge approach until the pattern became second nature. Our other teammate, however, was using the rebase approach. Now that we were giving Saif code review responsibilities, it was best for him to switch to the rebase style so he could learn from our teammate’s example while reviewing his work. Deliberately assimilating the rebase style as a part of his new code review responsibility provided several tangible benefits:

  • Flexibility: Saif can now switch back and forth between these two tools as needed.
  • Flow: It’s best for a code reviewer and reviewee to use the same approach. Saif could perform code review without disrupting his teammates’ development flow.
  • Efficiency: By taking some of the code review responsibilities off of my plate, we eliminated a bottleneck.
  • Progress: This freed me up to place more of my own focus on another important area of the project.

Our throughput skyrocketed, without the slightest dip in quality. Work tickets were getting implemented, reviewed, verified by our stakeholders, and deployed at an incredible rate. Even with a great deal of confidence during our sprint planning sessions, we found ourselves pulling many tickets from the backlog. We were able to roll off our veteran teammate ahead of schedule because Saif had it all well in-hand.

Support continued growth

This pattern repeated several times throughout the project. Every time I thought we’d found Saif’s limit, his visible progress told me that he was ready for another responsibility. Our approach was organic: We didn’t start with some bullet-pointed list of responsibilities and goals to work towards. Instead, Saif and his work spoke up, indicating he was ready for the next thing. All I had to do was listen for it, move more work off of my own plate, and offer mild course corrections and advice along the way. He was never a “junior” developer that I had to drag along, but a trusted colleague working toward a common goal.

Helping clients find a better way to solve problems with software begins with equipping our team members with the skills they need to operate at their best—but it doesn’t stop there. When mentorship is an active and deliberate part of your development process, you empower your team members to grow, while improving your overall throughput. As Saif moves on to his next project, I know that he’ll pay it forward. He’ll naturally find himself in situations where he can play the role of mentor, enabling his teammates to take on more and more responsibilities themselves, too.

Let's Talk