Hiring Software Developers (Part 2/2): Structuring Your Team for Success in a Tight Talent Market
NOTE: First, thank you for reading, and if you like this post, and want to work with some great mentoring and team building experts, look no further! DevFarm is here to help you build a culture of service through mentorship, and help you find and retain the best talent in the process. Connect with us here or just shoot us an email and we'll be in touch to chat about your hiring and retention needs.
In part one of this series, we talked about one way to define the different levels of software developer: junior, mid-level, and senior. We also talked about how mentorship helps both the mentee and the mentor, by improving overall knowledge through sharing, building team cohesion, and strengthening leadership qualities in senior developers.
In this post, we're going over what your team can do to succeed, and grow, in a tight market for software talent, and how structuring your team's time and making mentorship a higher priority, can multiply the efforts of the entire team and be the "rising tide that lifts all ships".
Structuring Your Team When Hiring is Tough
We all know that finding great software talent isn't the easiest thing to do these days. In the struggle to hire, there are proponents of keeping a very high ratio of Senior to Junior developers as well as a few, including myself, that think the ratio should be much lower. The ratios, on the high side, go from 2:1 to as high as 3:1, and also on the very low side, far below one.
For those that favor a higher ratio of Seniors to Juniors, the belief is that the Senior developer has an important job to do, in cranking out features for the product team, to help the business meet goals, and defeat the competition through engineering excellence. For those that advocate for a lower ratio, the idea is that senior developers are more than just "code monkeys" and have a responsibility to lead as well. This is the setup I prefer, with an even ratio of juniors to seniors, or one where juniors and mid-level developers outnumber senior developers, because of a few benefits we'll go over later.
But I Want all Senior Developers (and a Pony)!
You can absolutely have most or all of your team made up of Senior Developers. There's nothing wrong with this setup. In fact, it's what I've noticed is the preferred structure for most engineering teams I've been on in Silicon Valley, and elsewhere. Most engineering leaders I've come into contact with believe that it's a senior developer's main job to sit in the corner to crank out features, and do code reviews. From that, it follows that if we want the best work possible, then we need to have the most experienced, best developers working on it, right? Are there any downsides to this approach?
The Trouble With a Top-Heavy Team
Just like a car, a software team can be the sweetest, fastest ride in the world, but it still takes a driver (engineering manager, director, VP, or lead developer) to get it around the track. A team of all senior developers, though technically quite proficient, may lack in other areas and because of some possible challenges in interpersonal dynamics, there may be a few struggles on such a team because everyone believes their opinions are the best of the bunch. Here are a few related challenges you might face:
Too Many Cooks...
Senior developers do great work because of hard-earned experience, which informs their decisions in how they work. If you have a team full of senior developers those opinions can be difficult to reconcile with other developer's opinions, because regardless of how "Vulcan" we software developers believe we are, we've grown attached to our ways of working. This creates a natural source of conflict, and I've seen that the most dominant or vocal personality usually emerge as the leader on the team, and their opinions tend to prevail over others, regardless of merit. That can lower morale on the team, as the more submissive members of the team don't feel heard, and become less involved in decision making.
What's more alarming, is I've observed dynamics on teams like these turn abusive, especially as the dominance levels of the senior developers go up. In fact, there's a study that describes this very phenomenon of having "too many cooks in the kitchen," which concluded that having too many dominant personalities on a team, can significantly affect morale.
Biases and "Battle-born" Opinions
In my previous post, I talked about how senior developers are paid for the many opinions they form over the years, and though we won't admit it, a bias tends to creep in, because, hey, we're all human. These are biases such as what tools to use, what design patterns to implement, and unfortunately, these decisions can be made with more emotion than logic. Because of these biases, the best ideas don't necessarily rise to the top. Discussion around decisions becomes one-way, not collaborative at it should.
A healthier approach, I've found, is in creating an environment where ideas can flow freely not just from the senior to junior, but the other way as well. Creating a forum for this to happen, either during sprint retrospectives, or by allowing healthy debate in code reviews, gives everyone a chance to be heard. I've found, that with fewer senior developers, and more junior developers, there's a greater tendency toward openness and less of a defense of strongly held opinions, because naturally, there are fewer people around to challenge these opinions. Because there are fewer existential threats to a senior developer's standing on the team, there are fewer reasons to become defensive.
"None Shall Pass" Code Reviews
Because opinions are held with such strong emotion, code reviews from a team full of seniors can be very difficult to navigate from a junior developer standpoint. I've seen weeklong code reviews where a junior or mid-level developer were completely battered by a group of seniors on the team with the developer that submitted the work becoming sensitive, and defensive. What would have worked much better, and been a much more efficient use of everyone's time, is working through it in a pairing setup, which would still have taught the less-experienced developer everything they would have learned during the code review, but would have built up morale, camaraderie, and team cohesion, too.
Missing Out on Peer Leadership Opportunities
On any team, you not only have the main leader that determines the vision and direction of the team, but also the team members that can lead each other in small ways. This is called Peer Leadership, and on technical teams, it's how knowledge is shared, leadership qualities start to develop, and how leaders start to emerge.
When you have a team full of senior developers, if there aren't any junior developers to mentor and pass on knowledge, you lose the opportunity for senior developers to strengthen that leadership muscle. Also, if your lead developer leaves, which results in a vacuum in leadership ability, you won't have anyone trained and available to handle upcoming leadership challenges. They'll have to "wing it" when the time comes.
Team of Experts ≠ Expert Team
A team of expert developers, doesn't mean you've formed an expert team. Team cohesion doesn't happen when features are created and delivered in silos. Teams are formed when people work together and interact with each other to accomplish a common goal, which the leader is tasked with guiding them to accomplish.
There are ways of getting senior developers to work together to maximize the chance of this cohesion being developed, but it won't happen organically because there is less to share when everyone is working on their own feature set. Though this might be the easiest way to organize work, it will require some additional effort to get that team to work together effectively.
A Better Approach and Why It's Better
The ideal structure for most teams, I believe is 1:1:1 where you have a ratio of one senior to one mid-level, to one junior, which provides everyone at least some opportunity to mentor or be mentored by someone else. This may require that the senior and mid-level developers do slightly less coding, which may seem uncomfortable at first, but on the positive side, this gives the more experienced members of your team more purpose than just delivering code. Besides the "warm-and-fuzzy" feeling you get when you help other people out, there are a number of other benefits to this structure:
Building a Culture of Service
With a more even distribution of seniors to juniors, you have the chance to build a culture of service through leadership. That is, you serve because you're a leader, and you're a leader because you serve. This is in contrast to how we typically think of leadership roles, that "I'm in charge, so you do what I say." Though Servant Leadership is a general approach that has existed in the military, in particular the Marine Corps for a long time, the formal concept comes from Robert Greenleaf, in an essay "The Servant as Leader" written in 1970.
The main benefit for your team is your people feel supported because their leadership gives that support through service. This support happens in the way of knowledge to pass on, materials, and processes that help them get their work done more efficiently. Then, they do better work, become more capable, and learn to provide for others on your team, which is a sustainable way of doing business. This goes against the traditional view of the role a leader plays on a team, but is a much healthier approach because you're providing a culture of "service before self", and leading by example.
When there's more collaboration, which you get with this type of structure, you start to hear what someone was thinking or feeling when they wrote a line of code. You get to understand why they think the way that they do. You start to understand the way they see the world. You feel how eager they are to please you and other members of the team and prove themselves, everyday. This, my friends, is what empathy is made of, and I think we can all agree we need more empathy in the world.
Learning Happens (Both Ways)
In many professions there are lessons and concepts that are shared between developers, that when well-timed, can really bring home the lesson. Setting your team up with a structure that has collaboration built into it will increase the chances for these lessons to be shared. This sharing also happens much more fluidly in a conversation, as opposed to pull request salvos and emails.
Better yet, more experienced developers can actually learn something technical from a junior developer (I've seen it), but the most likely learning comes in the way of leadership, which is what actually happens with mentoring. This sets up the entire team, and certainly the senior developer for success now and in the future. Even if a senior developer has no aspirations for management or for ever taking a hand off of the coding keyboard, these leadership lessons will be valuable to any team, at home, or in the community.
Higher Retention Through Team Building
When people form relationships through working together collaboratively with mentoring and constructive feedback in code reviews, morale improves. When morale improves, people tend to stay. I recently talked to one particular junior developer that has been having trouble because there is no mentorship at his company, there are quite a few junior developers on his team, and people are starting to leave, mostly the senior developers. If there was a system in place where the seniors were actively mentoring, both of these problems would be solved.
Ok, Now What?
If you have a team of junior developers, the best thing you can do is to not worry so much, and embrace what you have, which is a team of eager individuals ready to learn and contribute. Once you convince your senior developers that their job is going to be more geared toward teaching developers their craft but will still include significant amounts of coding, then the transformation is well underway, because the developers will begin to see the benefits of it soon.
If you have a team of mostly senior developers, make sure the less experienced developers are starting to get attention. Then, as you hire junior developers, ease the senior developers into to this new part of their role, and stick with it, because it will work.
If you have this kind of an organization chart, then keep going. You'll have a stronger team than you would otherwise, so keep believing in the power of mentorship to make your team the best it can be.
You Can Get There From Here
As I mentioned before, if you'd like to have help making a transformation like this, DevFarm is really good at guiding teams through these changes. Connect with us here or just shoot us an email to see how we can work together to help change the culture of your team, and the culture of software. We look forward to working with you!