My friend Andy Keller planted an interesting idea in my head recently. He described a conversation he’d had around the distinction between passion and preference. The utility of this distinction struck me immediately. Sharing it seems like it might create some value. (Can’t help myself, according to a psychological inventory I recently took (DISC) I’m highly motivated by utilitarian values.)

It’s easy to find examples in the world of software developers where the distinction between passion and preference, by not being made clear, causes a lot of silly heat and not much light. A perl bigot, or a Rails fanatic, for instance, will argue endlessly and often thoughtlessly for the superiority of their favorite technology. The result is online flame wars, shouting matches, closed minds, lost opportunities, some funny videos, and stagnation. These people have misplaced passion. They’d be better off, and get more done, by recognizing that while they may have a strong preference for their favorite technology, their passion would be more usefully directed to higher-order issues like user experience, testability, or developer productivity.

A couple of years ago, on the Atomic Object blog, I described a simple model for determining the suitability of any particular team for a development project. Seems to me the preference vs passion distinction partly explains what my model pointed out. A team or company whose passion is skills, practices and process will be more suitable, and hence successful, than a team whose passion is technology. Atomic Object is a good example. We certainly have technology preferences, and some of them are pretty strong, but it’s not those preferences we’ll “go to the mat” for. Our passions are in areas like testing and validation, engaged customers, user experience, sustainable pace, and predictable delivery. Those passions cross-cut projects and supersede our technology preferences.

Our hiring strategy is consistent with the emphasis on passion as well. We don’t look for particular acronyms on resumes, and we’re usually skeptical about “one language” developers. We dig hard to try and figure out where someone’s passions lie, and we’ll pass on them if their motivations don’t line up with our values, regardless of the candidate’s mastery of any particular technology.

Another reason I was struck by the passion/preference distinction is I think our passions support our “why” (Simon Sinek’s idea that successful companies know why they exist, outside of what they do for customers, and how they do it). Atomic Object was founded on the belief that there are better ways of building software. The things we’re passionate about are the areas where we see value in working on those challenges.

My hypothesis is that companies who are philosophically aligned with Great Not Big intuitively understand the passion/preference distinction and are similar to Atomic Object. I’d enjoy hearing whether this resonates with others.