This morning, I decided to try out a new smoothie place. I walked a block out of my way, only to discover a “sorry, we’re closed” sign. On that sign were the company’s hours, stating that they should have opened an hour earlier. Disappointed and somewhat annoyed, I walked back to my bus stop. That store had lost both credibility and my business.

This got me thinking about geeks and credibility. There are two kinds of credibility we need to have: personal and technical.

Personal credibility is the easier of the two. Do what you say you’ll do. Communicate if you can’t for some reason. Admit when you’re wrong. It takes some work to squash your ego and do some of this, but it’s completely do-able.

Technical credibility is far more difficult. Especially if you’re working with systems and software that you did not build and that are not documented. Land mines could abound, and you’ll probably step on a few. Unfortunately for geeks, non-geeks usually interpret lack of technical credibility as lack of personal credibility, and schisms build.

As a geek leader, I’d like to say that there’s an easy solution to the schism problem, but there’s not. Especially if you’re a new geek in the company, people won’t trust you (since personal credibility must be built). Step on a few land mines (or have a few old pieces of equipment fail), and you have to start from zero again and again. The only way to build credibility is to maintain personal consistency and do your very best to fix the systems or software to eventually be able to maintain technical credibility. It’s frustrating, but necessary.