One thing that I had to learn about leading geeks was how differently each geek treats self-management. Some geeks preferred that I list out every possible task I wanted them to do and then chat about general priorities, leaving them to prioritize specifically for themselves. Other geeks wanted just a few projects at a time with specific priorities, allowing them to methodically match my requirements.

My difficulty with the latter type of geek was that I have a personal weakness when it comes to specific prioritization: I’m not specific within my own mind. I build clouds of projects of varying priorities and then try to utilize my staff to have all the projects in the top cloud covered immediately, and go from there. If I’m asked about the priority of project 1 vs. project 2, I find it easy to answer, but I find it more difficult to prioritize the gigantic list of projects and requests that an IT department encounters daily.

So what did I do? I learned. I realized that it was horribly inefficient for me to cling to my abstract thinking at the expense of assisting my team to perform at their best. If someone needed explicit priorities, I would either figure them out before assigning tasks, or (more often) actually sit down with the geek and determine precise priorities together. The latter approach had the advantage of bringing another brain into the prioritization process, and that different perspective led to better overall priority decisions.

It’s not all about manipulating the geeks; often, it’s about changing oneself.