Hiring for kindness: One simple question

Photo by Jeremy Thomas on Unsplash

One of the most important qualities I look for when I’m hiring someone to join my team is kindness. In the world of aggressive business culture, the idea of kindness can have a reputation for meaning that you’re “soft” or unassertive. (I won’t even go into all the gender politics involved in how we talk about what makes a successful leader.)

Contrary to that perception, kindness is actually a critical skill for effective teams, successful businesses, and positive organizational culture. Kindness isn’t contrary to assertiveness or to radical candor. Rather, kindness is the quality that allows for colleagues who:

  • work collaboratively with others without ego getting in the way.
  • give constructive feedback in ways that are supportive and effective.
  • create an environment of trust that is so crucial to effective teams .

So, how does one hire for kindness? There’s certainly some of the process that involves a bit of “spidey sense”, but given that gut feelings can be subject to unconscious bias, I’ve tried to find more structured ways to screen people. One method, which is pretty straightforward, is simply asking about it in reference calls. Seems obvious, but people are often surprised by the question!

The most useful tool I’ve found is one simple question: “How would your colleagues describe you as a collaborator?” The way someone answers this question provides a wealth of information. The responses I’ve gotten tend to fall into 3 categories:

  1. They’ve clearly never considered the question before in any depth. This is a big red flag because it means two things: It means that they aren’t intentional about their approach to collaboration, but it also means that they haven’t really thought about how their behavior might affect their colleagues or how others might perceive them.
  2. They speak to their own approach to collaboration but not what role they play in the team dynamics overall. This is pretty common and can be a fine place to start and grow from, especially for an individual contributor (if someone is leading others, I would hesitate a bit more). The only big red flag here is if the approach they describe seems more focused on their own success than the team’s success.
  3. The best situation is a highly self-aware answer, one which outlines how they think their approach plays out in the team overall and how it helps to support others. With this level of candidate, I usually see them explicitly thinking through how to help others grow and make space for everyone.

This isn’t a perfect science, but that one question can be very revealing about how a person works and relates to others. It has been helpful in providing a more analytical way to hire for kindness and try to bring in people who will make for a successful team and an organization in which people can thrive. I would love to hear about any other strategies you have found to approach hiring for kindness. Share your thoughts on Twitter @cog_sprocket!

Coding as Creativity

Maze-like output of 10 Print, a classical "code poem".
From @10print_bot on Twitter. For more information, see https://10print.org.

An executive recently confided in me that he was surprised to learn that developers cared what problems they were working on. “I thought they just cared about writing code, not what it was for,” he said, in what seemed like newfound respect.

While this might seem like an isolated opinion, many technology leaders direct their developers in ways that support this statement, even if they wouldn’t put it so starkly. Developers are often seen as interchangeable parts who can go from working on internal tools to email templates to site reliability to API development without a second thought. Further, the tools and processes we use strengthen this view; tickets are often assigned to teams who align on a certain skill, not a given product or problem set, and organizations are often delineated by understanding of a portion of a “stack” (front-end, back-end, APIs, etc.)

These distinctions make some logical sense (I’ve recently been guilty of organizing teams by these assumptions) but to foster true creativity, new techniques will be required.

More than any other technique (and I’ll write about others in the coming weeks) the one that must come first is to realize that development is not about writing code, but rather using code to solve problems. Too often tech teams are given tasks without context or goals, cutting off an avenue for innovation and creativity. With clear communication and trust, we can unlock the creativity of our tech teams by treating tech as a strategic partner and not a service bureau.

This begins with sharing strategy, goals, measurements, and reasoning with technologists, including everyone from the CTO to individual developers. Recent history is flush with examples of developers and engineers creating new lines of business within their organizations; Amazon Prime is likely the most successful of these. These contributions were only possible because these developers understood their company’s goals and could apply their unique skills to those problems.

Unleashing this creativity requires clear, candid communication. Only by sharing hopes and fears honestly will every member of your staff be in a position to contribute with all of their skills.

Once they’ve been properly briefed, developers tasked with solving a given problem should work together across boundaries of expertise. Whether you call them teams, squads, pods, whatever, people working together to solve problems will yield solutions that are both more creative and implemented more quickly. The tight feedback loop of design and interface development, or API development and information display, for example, creates this effect. If at all possible, this should include participation from design, product development, and even editorial and marketing, if appropriate.

Treating technologists as service practitioners will guarantee you get exactly what you ask for. Including technology in the early stages of defining problems and opportunities will mean getting solutions far more creative, efficient, and sustainable than you could have imagined.