The Need For Intellectual Honesty Starts With Me

It was my first ever full-time job as a software engineer in San Ramon, California, when I sat in a room full of corporate staff at the headquarters of K/P Corporation in 1998 or 1999. It was I believe the CEO/President who was giving a monologue, a state of the union address of sorts for the company. Alongside my raising my eyebrows that he was bemoaning the reality of disruptive technology and bothering to take the time to explain what it was and how and why it caused him pain, he also went over a few ideologies of desired characteristics of his staff, one of which stood out like a sore thumb: "intellectual honesty," he said, "the ability to admit what you don't know."

It sat on the forefront of my thoughts for a while because it was a term and concept I had never heard before. People don't usually discuss such things; quite the opposite, in fact; people are encouraged, whether they spell it out or not, to "fake it till you make it" and to put on a show of knowing anything and everything that you think you ought to know. Certainly the latter is something that I was struggling with, and often at times it's something I've struggled with ever since for my entire career. After all, no one knows everything, so if my pliable human brain isn't capable of filling in the gaps of knowledge as I need them, who can you hire? Right?

"The more you know, the more you realize how little you know."

I've since had a number of jobs--that's a number other than one--and as time has gone on I've reflected on this notion of "intellectual honesty", talked about it, blogged about it, and in the end I found myself looking at my colleagues and thinking, "They still don't get it." Coupling the notion with the saying, "The more you know the more you realize how little you know," I kept adding, ".. and those guys think they know everything! Boy have I learned how little I know!" Thus began the perpetuation in my career of genuine false humility.

Let's back up for a moment, before I get lost in Alice's rabbit hole of an undiagnosed psychological disorder that I seem to be wallowing in for most of my life (called "pride and introspective confusion"). As a professional software developer, my job is to bring knowledge and experience pertinent to the needs of my client, customer, or employer to assist them in accomplishing their preexisting goals. My job is not to do and be. My job is to help them do and be. This doesn't mean that my role doesn't involve doing skilled work, or being a skilled worker; what kind of help would I be otherwise? On the contrary, it is more important that I deliver knowledge and skill to the table than that I develop any motive of vanity. The reality of what I bring to the table will be apparent to everyone when I bring it. I don't need to convince myself or anyone else of what I'm delivering beyond what I've delivered.

My action objectives, therefore, should be to identify the course of business that the team is engaging in, recognize the objectives and all of the technical opportunities, hurdles, and roadblocks that stand between, and come prepared to tackle the challenges with minimal chance of failure. My own identity is not a part of the equation. But my reliability and my demonstration of respect for those I am working for most certainly are. In the end, as I succeed to demonstrate respect and reliability, others' view of me will always improve, but the moment I let it get to my head (ego) is the moment my respect for others diminishes--quite visibily and very quickly.

The polished picture of my end identity should not be someone everyone loves but someone whom no one needs to notice.

Refinement of adult maturity can be best illustrated by strong foundations, not elaborate facades. The polished picture of my end identity should not be someone everyone loves but someone whom no one needs to notice. If I lack knowledge or experience about a particular area that I know my customer or employer is engaged with, I should immediately take action and close that gap, not because I want to be the superhero that might save them from disaster but because they are conducting business and my lack of knowledge may potentially ruin them.

In contemporary Christian churches, people meet weekly to sing songs and listen to a message from a designated pastor. These places of gathering are usually outfitted with a loudspeaker system, typically a complete sound system with large speakers in the front near the stage and a big mixer and audio sources and processors in the back of the room near where the audience enters and takes their seats. There have been multiple times that I've heard pastors talk briefly about their under-appreciated technical team sitting behind the audio mixer, such as when the audio engineer goes on vacation. What I often hear is, "The best sound guys are the ones who you don't notice. There are no issues, everything just works, and no one is thinking about the sound system."

That's the kind of engineer each of us should strive to be. It's when we don't know what we're doing that suddenly the company must suffer slow-moving ramp-up periods and bug infestations in our deliverables. Mentoring is the necessity of those who understand to pull up those who don't so that business can proceed. Doing background homework on skills is not learning more in order to get ahead; it's filling gaps so that we can stop holding the team back. Constantly learning is not taking a hold of advantage to climb a ladder; it is a demonstration of humility and acknowledging that failing to do so is doing harm to the people we are helping to succeed.