Humility

2012-10-01

I was applying for a very senior architect role. I’d already been through several rounds of interviews with a whole committee of thought leaders in the department. I’d taken a technical proficiency test, and (I hope) given a good impression about how I’d be able to contribute.

The CEO cleared a block on her schedule and sat down with me. She poked a bit at my business experience, my ideas of process, and my aspirations. Then she said, “Tell me your thoughts on humility.”

I think it’s the best job interview question anyone has ever asked me.

A great perspective on humility. Photo credit: Chiot's Run (Flickr).

Real humility

A person trying to fake humility says, “I’m not very good” — but doesn’t mean it.

A person trying to be humble, but misunderstanding its nature, says, “I’m not as good as X” — and tells himself it’s probably true.

A truly humble person isn’t usually interested in comparing herself to others. She’s well aware that everyone — including herself — has both strengths and weaknesses. She is willing to learn, even when she already knows a lot, and even at the cost of admitting mistakes and blind spots. Humility doesn’t require her to artificially put herself down, or to artificially overvalue others; it requires her to remember, tenaciously, that problems — never people — are the enemies you strive to overcome. (For the religiously inclined, I have never found a more profound exposition on pride and humility than the one Ezra Taft Benson offered in the late ’80s.)

Why humility matters

Teams with humble members flourish, which is why the CEO’s question to me was so astute. Especially in senior roles, there’s a danger of becoming deaf to others and overly enamored of your own ideas. Proud architect = bad.

I have done some bone-headed things in my career (ooh, great idea for a series of posts!), and a large percentage of them were either caused or exacerbated by pride. Hopefully my future mistakes will come from something different.

How humility manifests in engineering teams

Disclaimer: this list represents ideals I want to achieve. I am definitely not a perfect example of this list. Yet or ever.

A humble engineer (or architect, or any other role on a technical team) listens to the ideas of other team members and then restates them, without skew or value judgment, to validate his capture of a different viewpoint. He regularly sees others nod and hears them say, “Yes, that’s a fair summary of my perspective.” Notice how this contributes to designs that balance many considerations.

A humble engineer is not overly territorial. He doesn’t suffer from NIH syndrome.

A humble engineer doesn’t exaggerate estimates, bug impacts, feature creep, or technical debt.

A humble engineer likes to compliment. She can probably give you a long list of things she’s recently learned from team members. Notice how this dovetails with learning voraciously.

A humble engineer is quick to admit inadequacies of her code, design, or experience. She is proactive about raising questions and concerns in her own work product, so that everyone can learn faster.

A humble engineer is fact-driven, not authority-driven. Perhaps he learned long ago that technique A is “better” than technique B. Perhaps he considers himself an authority on the issue. He may suggest that his experience argues for technique A, but he suggests this always remembering that past experience may not apply perfectly to new circumstances. If his suggestion is not accepted immediately, he is ready to engage based on data and facts rather than his own prestige or another’s lack thereof. He doesn’t try to “game” the data; he just allows truth to be its own witness. Regularly pursuing facts without a hidden agenda makes it safe to put a stake in the ground, because people believe it will be moved if need be.

A humble engineer does not blame others when things go wrong. This is not because a humble engineer is relentlessly trying to convince herself that others aren’t blameworthy; it’s because she knows that blame is not helpful. Instead, she sees problems and asks, “What can I do that would prevent this in the future?” She may also offer ideas about how others could contribute to the solution. She may be blunt. But she remembers that it is the problem, not other people, that are the enemy. This shows in the way she communicates.

A humble engineer cheerfully tackles mundane tasks, not just exceptional ones with lots of glory attached. See Helen Keller quote.

Action Items

Make a list of things you've learned from teammates. If your list is too short, pick something specific where you are willing to be taught.

Resolve to make a habit out of restating another person's perspective fairly and thoroughly.

---

Comments

• Jason Ivey, 2012-10-01:

  Great article Daniel! Had I been given that question in an interview I'm sure I would have handled it badly as I do with most interview questions. But you're right, it's a great question which really cuts to the quick. Keep up the great posts!

• Daniel, 2012-10-03:

  Jason: you'd ace that question, since you're a great example of the virtue it pokes at. :-)

• Stas Shaposhnikov, 2012-10-06:

  My feeling is something like this but until now, it was mostly intuitive. Thanks for the great article.

• Daniel, 2012-10-07:

  This is one of the reasons why I blog: it forces me to put into words ideas that have only been vague feelings before. I like being forced to think clearly. Thanks for the feedback, Stas. I hope things are going great for you.

• Smart Geeks Think Like Cheerleaders « Codecraft, 2013-02-05:

  [...] achieve something important, get enamored of our own success, and forget to be humble and to learn from [...]