When you’re recruiting new developers to your team, there’s a good chance you’re striving to hire “rockstars” or those mythical 10x developers. This makes sense—what better way to bolster your team’s effectiveness than to get the most knowledgeable and experienced candidate in Java, for instance, that you can find? As anyone with some experience building software can tell you, it’s not always that simple—just like it’s not always simple to figure out why a team isn’t producing results the way you expect it to. You might have the world’s foremost expert on a particular language or technology working on your development team, but sometimes your time-to-market keeps slipping anyway.
If it’s not all about technical ability, then what are the right skills to promote on your team in order to build the foundation for successful delivery? What traits should you be looking for in new hires, and what traits should you reward when existing team members show them? It’s a tough question to answer, in part because it’s difficult to sift out the platitudes from the simple truths.
This might seem counterintuitive, especially when you think about the concept of the 10x developer who does orders of magnitude more work than mere mortals. But marathon coding sessions aren’t inherently good for their own sake. If one programmer sees a mountain of repetitive work every week and jumps into it with both feet, that’s certainly valuable—but a lazier programmer who doesn’t want to do those tasks over and over again and instead finds a way to automate them has the potential to save time not just for herself, but for other members of the team going forward. Sure, that laziness needs to be combined with the creative impulse to automate and to find new ways of doing things—but someone who’s truly committed to avoiding sleepless, Mountain Dew-fueled coding sessions will find a way.
Another way to phrase this might be to say that you want people working “smarter, not harder.” But putting a focus on laziness is a good reminder that if successfully delivery frequently hinges on one programmer’s last minute, heroic efforts, there are probably real underlying issues on your team.
There’s an old joke when it comes to awards shows like the Oscars: To predict the winners of each category, substitute the word “best” with the word “most.” Titanic wins an Oscar because it’s the “Most Movie,” Jack Nicholson gets an Oscar for doing the “Most Acting,” etc. The idea that communication skills are critical to success is pretty obvious on its face, but even teams that place an emphasis on communication skills can fall into the trap of confusing the best communication with the “most communication.”
You can have an incredibly talented developer with excellent written and verbal communication skills—someone who’s eager to give a status update in every standup meeting—but if they let their tasks get blocked because they don’t raise their hand when they need help, they’re still going to slow down production. This might happen because the developer is embarrassed not to know something they feel like they “should,” or because they’re trying to smooth over what they perceive as weaknesses in their abilities. But the end result is the same: poor communication, and stalled stories.
So what do the “best” communication skills look like? Like proactively speaking up when you encounter a problem that you don’t know how to solve, or raising your hand when you come across a behavior in a given system that you didn’t expect or can’t figure out. In other words, giving the rest of the team the chance to get you unstuck, even if it means admitting that you don’t know something. Crucially, this kind of communication can’t work if it doesn’t go both ways—which means that the most successful teams will be the ones where every team member actively listens and seeks to help even outside the daily standup.
By now you may already be noticing the running theme in this article: it’s impossible to achieve such a complete knowledge and understanding of the field that you know the exact right approach to every problem or situation. No matter how experienced you are, no matter how much you know, you will sometimes find yourself in situations that test the boundaries of your knowledge. When these situations arise, some developers will just stick to the old way of doing things out of habit. This certainly isn’t the end of the world, but the most successful teams are built out of people who understand that there are limits to their knowledge—and who then make a point of exploring those limits.
This looks different in different situations: For instance, a team member might be trying to figure out why their code doesn’t type-check, and it occurs to them to see if there are tools that could help them scan their code for these errors before they run it, in order to save time. They find a few relevant tools out there, but they don't exactly fit their needs, so they create their own version. Then, the next time someone else on the team is worried about running into this problem, they can just use the tool that their teammate came up with. Thus, the intellectually curious teammate makes life easier and potentially more efficient for everyone they work with.
When a team is really firing on all cylinders, this kind of thing can have a cascade effect. With a group of developers who communicate effectively and are actively interested in saving labor and effort in the long run, it’s easier for everyone to see what kinds of tools and ideas will have the biggest impact. This, in turn, can motivate everyone to research, to learn, and to sharpen their skills and knowledge over time. The impact is that the whole team becomes better at delivering working software.
As a subset of intellectual curiosity, it’s helpful to pause for a second and talk about humility. Again, nobody knows everything, and those who act like they do are putting their projects in jeopardy. This applies to intellectual curiosity: You might have a teammate who’s constantly in search of the next new thing and always looking for new approaches and opportunities for innovation at each stage of the development process. If this is coming from a genuine desire to solve a problem and improve upon past work, the outcomes are likely to be pretty good—exactly like we talked about above. If this person’s motivation is actually to seem smart or cool, you might not get such good results. They might even come into sensitive situations insisting on solutions that aren’t well suited to the problems at hand—and they might not be great a hearing the word “no.”
None of this is to say that success demands self-deprecation. Just that one of the most important steps on the road to improvement is admitting that you don’t have all the answers. And constantly working to improve is one of the hallmarks of teams that produce functioning software on-time and on-budget. The time-to-market pressures that weigh on your average software development cycle are getting more intense every year, just as the technologies being used are constantly changing and evolving, which means that a development team that never changes will have a harder and harder time rising to the occasion as time goes on. And you can’t change without first recognizing that there are limits to your existing expertise.
Teams are social organisms, which means that the behavior of one teammate can have a ripple effect on the entire team. When you hire passionate people, their passion spreads to those around them, and it makes everyone more engaged—and thus, more effective. It’s fine to leave your work behind mentally at the end of the day, or to put all thoughts of whether or not your code compiles on the back burner while you eat your lunch. But the most productive software development teams—the ones who actually deliver working software on a consistent basis—are the ones who stay intellectually engaged with their work wherever they are.
This isn’t about hiring workaholics who never put away their laptops, and it’s not about hiring know-it-alls who keep spouting off the details of new security vulnerabilities while the rest of the team is trying to relax—it’s about creating an atmosphere that rewards people for being engaged. When the team is able to bond over its shared excitement about learning new technologies and solving thorny technical problems, it creates a positive feedback loop—everyone wants to contribute to the team that they’re invested in, and they make the extra effort to learn something new, or to think outside the box.
Again, the most important skills for your development team aren’t necessarily technical ones. In the same way that a series of closed Jira tickets doesn’t automatically turn into a complete piece of software without someone managing the pipeline that integrates those tickets into a cohesive product, a team full of technically-proficient developers won’t automatically produce working code without a sense of cohesion and dedication. The best way to get that cohesion is to start with passionate people and give them the support they need to get smarter, more efficient, and more effective over time. This is just as true when hiring your own team members as it is when finding an outsourcing partner or contractor.
Learn More About Intertec’s Software Engineering and Support Services
Intertec specializes in building and supporting custom software for its diverse clients. Our experienced team of interdisciplinary professionals have experience at all stages of the software development lifecycle. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!