Geek respect

I’ve often heard it said by those who’ve had to manage geeks (or want to have positive interactions with them) that they find that geeks have little respect for those outside their field — in particular for management and for those that perform non-technical work like administration (e.g. accountants and office managers) and user support. I don’t think that is the general case, and if you do have such a problem, it is often relatively easy to resolve.

Before we start, it’s useful to know whether you’re dealing with a geek or not. There are many people in your IT department who aren’t geeks, and respect may work differently for them. Also, there may be people outside your IT department who are geeks, and this approach will cover a lot of them too.

Geeks respect, simply, those who do what they do well. If the person in question has the geek quality of passionately pursuing a better understanding of what they do, so much the better. Or, in short, geeks get on well with other geeks — whether the other geeks know they’re geeks or not.

If you have geeks invested in your project’s success, they will generally react to people in three categories:

Respect those who make the project succeed;
Are indifferent (often) or dismissive (also often) of those that don’t seem to have an effect on it;
Are hostile towards those that they perceive to be hindering the project’s success.

(If you have a geek not invested in your project’s success, then you have bigger problems.)

Geeks within IT (those who develop software or manage systems, networks, or security) find it easy to figure out whether someone is a member of that group because they share a common language and practices. Every word out of someone’s mouth on an IT topic is going to provide an input into deciding if that person is a geek. It doesn’t even necessarily need to be a topic they are particularly skilled in, as technology is ultimately about systems and processes, inputs, conversions, outputs — and not concrete implementations. This process continues over time, with respect ebbing and flowing, until a large body of sample data causes it to get mostly pinned around a particular level. (Unfortunately, once this is set, it takes a lot more time and effort to change that perception.)

In topics outside of IT, this is often not the case. Unless you have geeks interested in technical writing, support, QA, or management, you can’t rely on
this discussion-based, respect-decision-process when dealing with those who work in those fields.

The most effective way to fix this problem is to engage a geek’s systems thinking and problem solving apparatus. Directly explaining how a particular person contributes to the success of the company or project or otherwise makes the geek’s life easier might work if you’ve got enough respect going, but there’s a big risk that it may be felt as an attempt to manipulate the situation.

It’s better for the person in question to figure this out themselves, by being given access to the information necessary to discover this. To explain this, perhaps an example is useful:

While developing on KnowledgeTree, my “team” of one quickly gained two additional full-time developers: Brad Shuttleworth and Bryn Divey. I’ll almost certainly talk about these two a lot more in future because of the great positive effect they and that experience had on me, but the short form is that this team growth went incredibly smoothly because we could easily measure each other up.

Our team grew quickly after that too, and as we gained more users (and especially more paying users) and more features, we needed to get more serious QA going on our product — an external set of eyeballs to flush out things developers might not consider bugs. Eventually we had someone working near full-time with us on the QA of KnowledgeTree around release time. Anna was the head of the QA department at Jam Warehouse, and her hard work in setting up the QA department and managing her QA team was obvious. That being said, that wasn’t a sufficient shortcut to gaining respect on our project, and things could easily have gone the other way with a different person. However, within a fairly short period of time Anna was a solid, fully-paid-up member of the team — we trusted she was talking from experience (even though we didn’t much understand her skill-set) and we trusted her commitment to the project.

How did this happen?

Perhaps the most effective means Anna used to gain our respect was her communication style. She informally kept us informed of how we were affected by problems she had, and how she proposed to solve the problems. She was also good at what she did — our bug tracker was filled with quality bug reports (perversely, the more bugs in a bug tracker, the more confident of the quality of your system one feels), and she found many show-stopper bugs just before important releases (which saved us a lot of time and a lot of ego). Seeing how much better she made the project, and seeing how she tried hard to make our lives easier, we were quick to try make her life easier, starting a virtuous cycle that continued while we worked together.

In too many situations, I’ve seen this fail when it shouldn’t have. In particular, it’s too easy for a manager to end up being perceived as being an outside influence on a project rather than a team-member working towards its success. When you’re considered a problem to be solved rather than a comrade in solving problems, you and your team are in pretty deep trouble.

In a way, a manager’s task is to understand the concerns of those around them, and to transmit and otherwise act on those concerns in order to best achieve the goals of the organisation. It is a balancing act, since one must be seen to be dealing with the concerns of all without too much prejudice. Some days you’ll be telling your board of directors that they can’t change the entire direction of the project for the second time this week, and other days you’ll be telling your developers that you can’t get them better coffee, more monitors, or more staff.

This may be counter to many company cultures, but sharing problems you face and have faced with your team, sharing your plans and your past successes (and failures) will lead to you being considered as part of the team, rather than being perceived as an outsider imposing seemingly random restrictions on the team.

Since it may just be luck or statistical probability that one or two non-tech staff have managed to earn very deep respect from the tech geeks at most companies I’ve worked with, I can offer SynthaSite as another example. Here, not just one or two, but pretty much every non-tech staff member commands respect from the tech geeks. I suspect, perhaps, this is why so many geeks are attracted to startups — they tend to try harder to hire the right people, whether they’re tech staff or non-tech staff. I suspect SynthaSite may take it a step further than many &mdash. Many startups will have great developers and great managers and great financial guys. They often don’t focus on getting a great office manager or a great support person. It may be hard to believe, but when you’ve experienced it, you’ll know it, and want it that way forever.