Picture this... a young woman, with piles of paper all around her. Each sheet containing a photograph and a "short sheet", a quick glance of key information about an individual. The goal, take these hundreds of pieces of paper and organize them into 5 piles. Four piles of 40, the number of individuals that can fit on a tour bus. And 1 pile of the rest, to touch base with for a future tour.
Once upon a time, I was responsible for leading immersive experience trips for college students. For the summer trips, we would receive upwards of 300 applications, for 3-4 buses, with 40 spots on each bus. Seems easy enough, right? Just put people on buses... maybe group them by age or just randomly, they'd have a good time. But this was the trick. These immersive experiences were meant to be life-changing. They were meant to have an impact long-beyond the course of just the trip experience. To create lasting friendships and memories that persisted for years to come. For that to happen, the trip itinerary was one piece... how you moved a group through the experience gradually and stretched their minds but, more than that, the actual people in the group had a tremendous impact on the experience as a whole.
This is how I still think about teams today. Think of teams as puzzles, with each individual serving as a unique piece that fits into the larger picture. And putting together excellent teams means more than just looking at resume bullet points. So how do you start to hone this skill? And can you do this without the gauntlet that is the usual tech interview system?
I'm not gonna lie, it takes time and practice to hone this skill and get to a place where you can ask the right questions and know how to read between the lines on answers in order to determine if someone will be a good fit or not for the team you're building.
Step 1 is to know who is on your team and what skills and personality traits they bring to the table.
For technical skills, what does familiarity and expertise look like for each individual? (Note I said familiarity and expertise, not years of experience because someone with less years of experience can still be more comfortable or knowledgeable in a certain area of the codebase). What languages are they familiar with? What have they had exposure to in the past? What do they enjoy doing and what do they dislike digging into?
Assessing non-technical skills is a little trickier... how do they interact with conflict or conflicting opinions on the team? How do they communicate - both written and verbally? What does it look like when they resolve issues? When they look at new codebases or new areas... what's their approach? Do they hold the team together in any way?
When you have a good baseline sense for each individual, you can start to think about how these situational or behavioral traits interact together in order to understand the dynamic and balance that exists on your team. People build off of each other so thinking about the variety of personalities and how they cooperate and conflict (in a healthy way) with one another is critical.
Step 2 is to determine what you need. When you think about the best teams you've worked on, or even the best ones you've observed, what was their "it" factor? It's usually the result of lots of different personalities and types of people coming together... someone who's really extroverted, someone who asks a lot of questions, someone who makes and creates jokes and brings levity to situations, someone who helps balance that with understanding the seriousness of some things, someone who takes a little bit to mull over information before providing thoughts or opinions. And these don't have to be all individual people, it's the collection of characteristics you're looking for.
Balance that with technical needs... How deep is your bench for your critical technical skills? Will you need to stretch into different programming languages in the future? And if so, is there someone that would be a good guide for others in that scenario?
While this might seem overwhelming, especially if it's your first time, understanding your team members on an individual level and observing their group dynamics will make it easier to identify which puzzle pieces are missing that, if added, would bring everyone together and make the entire team a little bit better. Although beyond the scope of this article, the same strategies can be employed to identify individuals who may be exerting a disproportionately negative impact on a group.
Step 3 is to craft questions that helps you assess these traits to see how they might balance with your team. There are many articles and posts that hotly debate the best way to assess a candidate's technical skills (I have my own opinions as well that I'll opine on in the future) so here, I'll focus on some of the other skills you might be focused on hiring for. So, back to my buses... seems like a lot right? To interview 300 candidates, decide who would be accepted, and put them all onto buses... seems like it would take a while. Well, I had about 2 weeks. 2 weeks to to interview every individual, make decisions, and get them sorted on a bus (or not). The questions I asked had to be brief. They also had to be informative enough that reading the notes of interview 1 would still mean something after interview 201 and straight-forward enough that I could rely on fellow teammates to conduct interviews as well and get adequate enough notes to make decisions. Those interviews were 15 minutes each. They asked 3 questions:
- Which friends are you applying with and how do you feel about potentially being on a bus without them?
- What activities are you involved in?
- What do you hope to get out this experience?
In addition to that, the "short sheet" had their name, year at school, and major (or what they were thinking about majoring in). It seems brief, it seems like how could I get enough information in 15 minutes and with just these 3 questions to break people up into groups that would help them have a life-changing experience, but it worked. It was just enough to get a sense of them, who they were, what their personality was, and what they loved. Using this information, I'd put together buses that had a little bit of everything... the really positive folks who would lift everyone up on tired days, the super aware folks who would make sure that everyone's voice got heard, the extroverts, the folks who did glue work, the ones who quietly helped, and the ones that pushed boundaries and challenged questions or situations. All of these different types of people were critical to bringing everyone together in a way that just worked.
Despite the tech industry's notorious reputation for multiple rounds of interviews, a clear understanding of the kind of person and skillset needed can ensure the successful filling of any gaps in your team. Those are usually behavior or situational interview questions. I'll give a few examples:
- Tell me about a time you mentored someone and what you learned from that process
- What's something you've done for your team that you've found really fulfilling and meaningful? As a follow up, you can ask how they got other teammates involved or how teammates felt about it.
- How do you usually approach providing a code review?
- Tell me about a time you disagreed with someone. What was it about and how was it left?
- What's something thoughtful that a teammate or manager has done for you in the past to show appreciation?
A team is a puzzle where all the pieces need to fit together. A team is an orchestra that sounds beautiful when it's working together really well. A team is also a living being. Every time someone leaves or someone joins a team, it's a new team, a different team, that has a different personality. Teams are constantly evolving and changing. People are constantly learning from one another and advancing or improving their skills in different ways. Being able to see who your team is, where they are at, and what they need to be even better takes practice, but do it enough, observe it enough, and you'll continue to keep getting better at it.