Hiring for Culture
By Chris Evans, Vice President Of Engineering at GoDaddy
After more than 25 years
in the software business, I thought that I had mastered how to hire great software engineers: I’d ask some good questions about their passion for building great products and delighting customers, add a few coding questions to help suss out their creativity and how they think through problems, and then evaluate the code they actually wrote. If that all went well, I’d hire them. If some parts didn’t meet the bar, I’d fall back to the old adage "if in doubt, no hire".
When I arrived at GoDaddy, I used these same patterns for my first few hires but I began to notice a problem. A couple of the new hires were smart and were able to solve problems but I started seeing issues in the sprint planning meetings and in code reviews. These new hires could certainly still write good code, but when others asked them questions about their solutions, they got defensive rather than listening to feedback. In planning meetings, they dug in on their idea rather than work with other members of the team on how their part fits into the larger system. Worst of all, some would create conflict, or not know how to diffuse conflict and would look to managers to resolve these questions rather than engage the other members of the team in an open discussion about how to move forward. The problems with these hires weren't with their technical skills - generally all of the solutions they came up with were workable with some level of trade-offs - they were cultural.
The team members with the biggest issues tended to come from companies where they had been “top dog”; either as very senior engineers in a big company or as the most senior person in a startup. In the culture of their previous jobs, they weren't used to people pushing back on their ideas and viewed that pushback as disrespectful or aggressive. Rather than working with more junior engineers to figure out the right path, they were more used to dictating designs. They could certainly quote customer needs for their arguments but generally just when it helped to promote their idea.
It doesn't take much of this behavior to create a challenging, if not toxic, team environment.
Some of my other teams didn't have this problem.
They were open and collaborative, engaged in pair programming, were quick to join forces with other teams to remove barriers that might slow the larger product effort. They created opportunities to mentor each other and maintained a growth mindset. Needless to say, the teams that worked better together also delivered better products and they did it more reliably.
Like most tech companies these days, GoDaddy engineering teams do not deliver products in isolation. Building products involves many engineering teams; from backend services and architecture through front end, web and mobile experience engineers. We can’t ship software that helps our customers without the contributions from marketing, customer research, customer care, design, international and myriad other groups across the company. We must have a culture of trust and collaboration that spans all of those relationships in order to deliver great products.
I’ve started reading up on team dynamics
and emotional intelligence as it applies to groups. I’ve spent some time talking with a management coach on ways to change the dynamic and fix the culture on the teams that were having the challenges. I’ve also worked with the members of each team. One of the key realizations I’ve come up with is that this starts at the beginning - during the interview. To build a great team here, we need more than just people who are great at coding and have a passion for delivering great products (though those are certainly important). We need people who value collaboration, trust, continuous learning and teaching. In my interviews, I’ve started asking questions about not just their motivation and technical background, but what they think a good team culture looks like. I want to know about times when they've had disagreements with coworkers and how they managed it, or what happened when a project went off the rails. We’ve started having people do pair programming for coding questions in order to see how they work with others to write code. What is their give and take like when there are different ways to solve the same problem?
The results, so far, have been great. Our hires over the past few months have been stellar. Not just because they are very bright engineers but because they are inclined to jump in and help or coach others. They engage in internal open source projects run by other teams and provide feedback and support in Slack channels related to GoDaddy's technical standards. They build better networks across the company and use them to socialize and get feedback on new services and APIs. They are more likely to allow decisions to be driven by data than by gut feel and they also tend to embrace our agile best practices. I'm still working on defining and growing our collaborative culture within our teams but starting with people who are more inclined to pair and share and who maintain a growth mindset has accelerated this process.
Our teams, and their culture, continue to evolve as new people join the company. Our culture is a reflection of all of our team members. When we hire people that are great at living our values we continue to get closer to our ideal: creating uncommonly good outcomes for our customers, growing as individuals, and having a great time together doing it.
BTW, we're hiring!