When one takes on any task, it's easy to interpret it in the most familiar terms right away. It can take a while to realize that what you thought was the problem isn't actually the problem.
For example, this famously happened to Bruce Schneier, the computer security expert. He wanted better digital privacy and security, so he concentrated on improving and disseminating knowledge about the mathematics and protocols of data encryption. But gradually he realized that that stuff wasn't the real problem — the real problem how to make security easy enough that people wouldn't screw it up. If you read Schneier these days, his attention goes mostly to human factors, because he learned that the human is the weakest link in the chain.
Personally, having such realizations has always been hard for me. I usually want to get to work right away, and want to feel that I understand the parameters of the problem completely; once I'm in a conceptual framework I get comfortable and want to stay there. This leads me to wrongly believe that I know the problem, instead of keeping my mind open long enough to let the real problem in.
But wait, there's more — see, even in answering your question I didn't fully understand what the problem was until I started working through it!
The further challenge is often convincing everyone else that what they think the problem is isn't the real problem, and that some other thing is. Any time you undergo a conceptual shift, you immediately have the problem of convincing other people in or near the same mental space that the shift applies to them too.
Nowadays when I start working on anything, especially with other people, I try to maintain an attitude of mild suspicion at the outset (of the problem, that is, not of the people). Sure, it's possible we'll all understand the problem right the first time… But it's just as likely we won't. The larger the group, the more momentum there usually is to settle on a common understanding quickly, so the group can get to work. Resisting that inertia, both in myself and in the group, is the toughest challenge.
2. What is the main source of inspiration for what you do?
Without a doubt, the free software movement. Since I first experienced the dynamic that arises when people collaborate on shared-but-replicable objects — that is, on things that cannot be monopolized — I've never wanted to work any other way. All the interesting parts of human interaction are still there: personalities, relationships, craftsmanship, appreciation and criticism, gift and non-gift economies, and yes, power games and territorialism too. But the nuclear threat is gone: the ability of one party to rule another party out of the game is simply not built into the physics anymore. It's a classic example of how empowerment is not always a zero-sum game. Sometimes you can empower *everybody* and it actually works.
3. What activity should be on every manager's daily list?
Mentally rotate through the people you're working with and ask yourself "What's frustrating or upsetting this person lately?" The answer might be "Nothing". But sometimes, if you just pause long enough to give it some thought, you'll realize that you've been subconsciously aware of a colleague's frustration, and once that's brought to consciousness you might be able to do something about it.
4. What can we learn from you in the near future?
Well, I have a highly specific answer for you :-).
O'Reilly is coming out with a book called "Beautiful Teams", similar to their popular "Beautiful Code" book, but concentrating on what makes teams run well. As with the first book, each chapter is written by a different author.
My chapter is about the importance of paying attention to collaboration tools — the idea that there may be nothing wrong with your teammates, but that instead the group's collaboration problems come from either poor tools or poor tool usage. I'm using "poor" in a very broad sense: a tool that looks good and is, on the surface, satisfying to its users can still be considered impoverished if it lacks a feature that would help everyone and isn't that hard to implement.
For example, why doesn't mailing list software put the archive URL of each mail right at the bottom of the mail? Most list managers are happy to insert all sorts of other things there: subscription and unsubscription information, links to FAQ pages, etc. So it's clearly not that there's any aversion to inserting snippets of advice in the mail footer. But the things generally inserted are about enabling an individual user to help herself: here's how you unsubscribe, here's how where you find the FAQ, etc. Whereas if the archive URL for that mail were right there in the mail, it would encourage the practice of referring to original sources for things already said, and thus reduce repetition. In other words, it would improve collaboration — it would help people help each other.
(I think the answer is just an accident of software design: most archivers were designed independently from the rest of the mailing list manager. In fact, in some systems the archive is literally just a subscriber to the list, like anyone else. This means that by the time the archiver is archiving the mail, the mail has already gone out, so it's too late to insert that footer. But these are all solveable problems, of course.)
By the way, they're also coming out with a "Beautiful Architecture" book (referring to software systems architecture, not physical architecture). I didn't write anything for that, but I've got a preview copy and so far it looks very good, so I want to recommend it along with "Beautiful Teams" for those interested in software development.
5. What is more interesting than software development?
Gosh, what isn't?
I could start listing all the things in the world that are more interesting than software development: people, nature, politics, choral music, languages (human, not computer)… But that's the way we all answer this question, because, you know, every geek wants to show that they're deeper than that, that they're not just about writing software. Perhaps the geek doth protest too much!
So maybe a better way to answer would be to say that software is just a mediation between people and people, and between people and data. Both the people and the data are usually more interesting than the software itself. The process of software development can be quite interesting, but at the end of the day, you can't have a conversation with a machine, you can only have conversations with other people.
Well, these are the answers given by Karl Fogel. I hope you liked them!