If you built an NFL team with nothing but quarterbacks, it would be the worst team in the history of the league. Just imagine a line of quarterbacks trying to block the defense at the snap of the ball, it'd be disastrous. But when it comes to hiring, too often, engineering managers are trying to do just that. It's common to think you need the best engineer, and that's defined as someone that can do everything from CSS to infrastructure. But in reality, unless it's a team of 1, it's quite unlikely you need someone who can truly do everything. Therefore, when you're hiring, take an hour or so with your team and outline what the strengths and gaps are for that particular team at that particular moment in time, and make sure you do so in a way that looks to build the team up, rather than tear anyone on the team down. It's not an exercise to say "Ashley always has bugs when she adds a new screen" or "Dan's database queries take way too long to execute." Instead, start by calling out what the team is doing really well. These are things you DO NOT need to hire for. Which means, if you interview someone who is great, except for the things your team does well, that's ok. After you have a list of what they're great at and what they could use some help with, break those in to 2 categories: needs and wants. For example, one team I was hiring for said they were just "ok" at TypeScript but they felt like they weren't using it to its full potential. Originally, we listed this as a need, but after more discussion we realized it was more of a want. We were good enough with TS, and we were continuing to improve in that skill. Conversely, there were some other skills we identified needing more immediate help with. Focus on getting your absolute needs to a list of 2, or at most 3, items. Any more than that could become a lot of burden for a single person to shoulder. Take those needs, and use that to shape your job description. You don't have to list every possible technology that your team does. Instead, focus the job description on what you _actually_ need from this person. This upfront work does take some effort, but it pays off in the long run. When you get 100 resumes, it's much easier to parse out which ones actually have the skills you're looking for. It also helps in the interview portion, because now you have a clear definition of what you're looking for. How many times have you been in a discussion where the team is trying to decide between 2 candidate that have slightly different skillset? By knowing what you're looking for up front, you can avoid those conversations. tl;dr: Don't try to hire more of what you already have on your team. Instead, focus on the gaps, and hire for what your team is _actually_ missing.
David Weiss
3mo
Great advice, Nate. I've always seen the benefit of hiring specialists or engineers who have clear strengths since that describes me. 😅 These types of people can add immediate value to a team. I also don't believe Fullstack Engineers are truly fullstack. Even when skills are equal (which they usually aren't), passions and interests rarely are. I've never met someone who loves writing CSS and SQL equally. 😂
@MOGov would mistake me for a hacker | Full Stack Web Developer | JavaScript, Ruby | Linux (I use Arch btw) | Scrum (PSM I)
3moWell this is hilarious to run across just after starting Blue Lock 🤣🤷♂️