Humility is a highly valued trait in our team members at Atomic Object. This is best exemplified when Atoms admit that they do not know the answer to a question—something I drive for when interviewing developer candidates. How they respond can tell a lot about how good of a fit they will be. Is their “I don’t know” defensive and argumentative, or is it curious and collaborative?
The question isn’t always explicitly delivered, though, especially as a software maker. We don’t know the answer to questions about the right approach to a performance optimization, the behavior of a third-party library, the reason for a failing test, or how to approach a design problem. But we likely have a strong idea of what the answer is, or the “right way” to get closer.
The manner in which we share that idea with a peer sets the stage for either collaboration or competition.
It takes bravery to admit to a peer that you don’t know something. It takes humility to admit it in a way that favors inclusion and alignment over staking your claim for taking credit or being right (a.k.a. #winning). Employing curiosity can make it easy to be both brave and humble at the same time.
Say we’ve just sat down and are pairing on a new, tricky bug. All we’ve done so far is reproduce it using the UI. I have an idea of what the problem is, so I say, “It’s the backend API. The response format is broken.”
When I share my idea in this manner, I’m making a definitive statement. If you have another idea, your most direct opening to discuss it with me is to submit an alternative idea. Another way you could respond is to simply challenge my idea, say by asking for evidence. Either way, I’m essentially making you argue with me in order to collaborate. That sucks.
However, what if I take a more curious approach and say, “I think it’s the backend API. Wanna take a look at the format of the response we’re getting and see if it’s valid?” Now I’m submitting my idea as a hypothesis—by prefixing it with “I think” and offering a test that could easily prove me wrong, I’ve admitted that I don’t know the answer. I’ve also expressed that I’m interested in learning more about whether my idea is right or wrong.
Taking this approach provides more openings to respond and collaborate. You could still tell me I’m probably wrong or submit another idea, but you could do so in a way that forges a plan of what to look at next. Or you could suggest a quicker way of testing my idea, say by looking in the error log.
That’s fun. Now we’re solving a problem together instead of taking turns to see who gets to be “right.”
So remember, try to be curious. “I think; let’s test” instead of “It’s this—I know” will always lead to a more collaborative conversation and a much more fun team environment.