Effective Collaboration: You Don’t Need Superstar Developers
I notice a few recurring themes when I talk with prospective clients. One is about looking for the lowest price and ignoring the value of the provided service. I’ve already written about this before. Another one is fishing for an appealing, i.e. low, estimate and ignoring all the issues that make estimates unreliable. One more is about focusing almost purely on technical skills of engineers. Let me ponder on this one.
First of all, what’s wrong with looking for best available developers? The short answer is: you end up with a suboptimal and less effective team than what you could have. It’s as simple as that.
Let me explain. It all starts when we talk about people who will potentially work on a new project. Fairly regularly I get asked about the exact number of years working with a list of specific technologies. Alternatively, it’s simply a request to get a full resume with the same goal: to see how much technical experience a developer has.
The trap is not in asking about specific people but in the traits that most people look at. Most often clients are tempted to look purely what’s the technical skill of an engineer and how technically experienced they are.
The first obvious issue is that a year of experience doesn’t equal a year of experience. Two engineers with different mindsets exploit a similar experience to very different extents. The same engineer working in the same technology in two different organization cultures would learn different things.
However, the main problem here is that software development is not an individual sport. Assessing technical traits means that we are looking at candidates as individuals. At the same time, we will put them in a team context and the project’s success will depend on their teamwork. A person’s resume or LinkedIn profile says close to nothing about their team skills.
What’s more, we know quite a lot about what makes teams effective. Anita Woolley’s research on collective intelligence provides extremely valuable insight on the topic. First of all, how do we define collective intelligence? It’s basically the skill of a group to solve complex problems. Well, it sounds like the definition of everyday work for software development teams if you ask me.
Why is collective intelligence so important? Exploiting collective intelligence, as opposed to going with the opinion of the smartest person in a room, is a winning strategy. To put in Anita Woolley’s words: “Collective intelligence was much more predictive in terms of succeeding in complex tasks than average individual intelligence or maximal individual intelligence.”
In other words hiring only the smartest people isn’t the best strategy to build effective teams. In fact, the research showed that there’s no correlation between the individual intelligence of team members and collective intelligence of a team.
If individual smarts don’t affect collective intelligence, what does? It seems there are two factors: social perceptiveness and evenness of communication. Social perceptiveness is all about seeing how others act and understanding why. In a way, you might boil it down to empathy. Evenness of communication is about giving everyone roughly equal chance to speak up, not having some parties dominate the conversation.
Teams that have these traits shine when it comes to solving complex issues. Again, these are not the teams where team members are the smartest or those that are most technically capable to do the job. Looking at this, I can’t help but wonder when a prospect clients are going to start asking me about these collaborative aspects of teamwork rather than proficiency with React, Angular, Ruby on Rails or what have you.
The research on collective intelligence was a heavy influence on the changes we introduced to our hiring process. As a matter of fact, the primary reason for introducing Happy Hours (almost a day-long visit of a candidate at our office) was to create an environment where we can see how a candidate acts in a team setup.
When I share the story on collective intelligence, almost unfailingly I hear that the research is irrelevant in our context. The argument is that our work in software development is specific and we actually need technical skills in the first place. I have an intuitive answer for that. Well, yes, we need technical skills. At some level. That level is defined by requirements, context, etc. In our case, we want a new hire to be able to act as an independent contributor, i.e. their work doesn’t have to be double-checked. We also focus a lot on craftsmanship since it means that we all are getting better at what we do and at a good pace.
The important part, though, is that once someone’s technical skills are “above the bar”, wherever the bar is, we focus on collaboration skills. This means that most of the time we would pick a different candidate from the pool as the best than almost every other company. It’s unlikely we would go for that rock star developer when we can hire someone with a teamwork superpower. The superpower, which helps everyone else around them be better.
I was convinced that this was the right path, even though I had only anecdotal evidence to support such a strategy. Ultimately, I can see how well our teams collaborate with each other and with clients. However if you asked me for a proof for quite some time a story would be all I had.
Then I stumbled upon the outcomes of Project Aristotle. It was a project run internally at Google. Its goal was to find what makes high-performing teams. One of the early realizations was that there are teams that are systematically doing better than other teams. So they started looking for patterns. Unsurprisingly, they couldn’t connect individual, or team’s, technical prowess with success rate of teams. Did they find an answer then? Oh yes, they did.
As Charles Duhigg, bestselling author and Pulitzer-prize winning reporter for The New York Times, framed it “Google’s intense data collection and number crunching have led it to the same conclusions that good managers have always known. In the best teams, members listen to one another and show sensitivity to feelings and needs.”
One could literally translate it to evenness of communication and social perceptiveness—the factors that Anita Woolley’s team nailed as sources of high collective intelligence.
What I’m saying here is that the common notion of what it takes to build a successful team is fundamentally flawed. And there’s good evidence for that. When we think of an exceptional team we simply have to think of team dynamics and not of individual traits. And yet we keep hearing from prospective clients things like “please send me a resume of your developer with x years of experience in my tech stack”.
Our idea of a successful team is one that will help to build a successful product for our customers. It’s is all about good collaboration. And when we say ‘collaboration’ we have specific team dynamics in mind. We want everyone to participate in conversations. It doesn’t matter whether you are a seasoned veteran or last year’s intern. What matters is that you have good ideas and the team can build on these.
We want people to take care of each other. We don’t hire for rock stars who go at their own pace and don’t look back. We need people who are perceptive and sensitive for others because that’s what turns average teams into exceptional ones.
It’s not to say that we don’t care about technical skills. As a company we’ve passed on quite a few opportunities and not because we didn’t have engineers available. We did so because we didn’t have people with the right skill set available.
It is, however, the same as with hiring. Once all the basic technical skills are covered, we primarily look at team skills that improve collaboration and increase collective intelligence. That’s what makes our teams different. And that’s what makes Lunar Logic different.