Marco and I have been talking a lot about the role of leadership in organizations. We’ve gotten on to a lot of different tangents, but there’s one important point I’d like to make out in the clear.

Marco’s Bro writes:

When I put someone in charge it’s because I want them to use their discretion — I believe they can be successful. I trust their judgment.

I expect that their team members will support them. I don’t expect unquestioning obedience or anything, but I expect everyone to realize that Leader Guy is, in fact, Leader Guy because I thought he was the best person for the job.

I know Marco’s Bro and, in real life, would probably accept most of his decisions. However, I disagree with this way of thinking in a general sense. My response to his statement goes like this:

What if you made a mistake? What if Leader Guy deceived you into thinking he’s more capable than he really is? What if he’s no longer as capable as he once was (personal problems, brain injury, etc)? What if he’s now out of his area of competence (see: the Peter Principle). What if you only rationalized to yourself that he’s trustworthy, when in actual fact you installed him because he’s dating your sister? What if your trust in him stems from his Harvard degree that his father bought for him? What if your boss chose you because he knew you’d choose That Guy, who happens to be his nephew?

Authority is a dangerous thing. When you trust in vested authority over other qualities then you put all of your eggs in the basket of the authority figure; your risk has gone up dramatically. That may turn out OK if the leader happens to be a good decision maker. However, thousands of years of history have shown us that following the leader doesn’t always work out well, and can often be disastrous. I’m sure everyone has been in a situation where they’ve had to accept the authority of someone who, on the face of it, shouldn’t have been given that power (I know that everyone in the U.S. has).

Marco and His Bro have stated that they don’t expect unquestioning obedience in the leader, but that when the leader has made a decision, they expect the rest of the team to go along with it, even if they think it’s wrong. This strengthens my argument against authority while at the same time cuts its legs out from under it. Yes, you want your leader to be taking the arguments of his subordinates into consideration. If, at the end of the day, he rejects them regardless of their validity, then they may as well not have been voiced in the first place. Both Marco and His Bro have said that if they’d heard of dissent escaping from the confines of the team and propagating up to their level, they’d tend to trust the leader and think of the dissenter as a troublemaker. Of course, that may true in a some cases, but this policy definitely puts a chilling effect on dissent that could be beneficial (or even critical).

In one of my instant messaging chats with Marco, the topic of religion (very briefly) came up. Religion is, of course, the ultimate in authority, both in a supernatural and in a real-world sense. Especially in monotheism, a deity has overwhelming power over its followers, who in turn have none over it. That deity, in turn “installs” its own hierarchy of people to act as a local authority on its behalf — at least according to the people in the hierarchy. Since these people supposedly have privileged access to the deity, they are effectively granted authority by the followers. Religion is particularly good at suppressing dissent, through everything from genocide down to making virtues out of trust and belief without evidence.

Evidence and reasoning are the keys to overcoming the risks associated with authority. They are the great equalizers, because Nature doesn’t care one bit about who has granted authority to whom — but with enough evidence and reasoning you can navigate the rules that Nature has put in place and use them to achieve your goals.

It may very well be that the chosen leader makes successful decisions because she applies the best evidence and reasoning to a problem. Ideally, this should be true in every case; you can make the best decision possible in the shortest amount of time when you don’t have to explain and justify it to others. But we all know that this doesn’t happen every time. Even if the leader has the best reasoning skills, she may not have the best evidence, and so her conclusions might be suboptimal.

This is why I reject authority that exists for its own sake. If an authority figure makes a decision, let the decision stand on its own merits, not on the position of the person who makes it. If it’s a good decision (based on the reasoning and on the evidence), then it’s worth supporting. If there’s an better one, let it be the course of action, regardless of who proposed it. If gathering evidence is too costly (and it often is), then it’s OK to go with the assumptions of the most “experienced” person on the team, but be prepared to reject those assumptions when the evidence contradicts it. Personal experience is a valid argument (we rely on it for a great many decisions), but it’s a weak one, and it should be overridden and/or augmented by objective evidence whenever possible.

Authority, at best, illegitimately takes credit for success. At worst, it leads to failure. Be skeptical of it at all times.

In many (most?) organizations, “being a team player” is code for “being nice” &emdash; which, in turn, is often code for “not contradicting anyone.” The problem with this is that it leads to groupthink and mediocre (or often just plain wrong) results.

I think that this Slashdotter has it right: (emphasis added by me)

I’ve worked for years in highly effective teams, and with success. I can tell you what made all the difference: The presence of equals to debate issues with, so that we could talk each other through the problems and emerge from the session with the feeling that we had defined better solutions. Perhaps we are all arrogant nuisances, but as long as we understand and respect each other we keep each other in check, and can function as effective team members.

The “respect among equals” also translates to “respect among people above and below you in the hierarchy” when such hierarchies exist:

• Listen to & consider what your boss says, but call him out on it when he’s wrong or hasn’t justified his assertions.
• Listen to & consider the objections of those below your skill and/or station, but correct them when they’re mistaken and clarify the reasoning behind your positions.

You should only be stating agreement when you reach the same conclusions based on the available information. If you don’t think you have enough information to defend a contrary position, it’s better to state that outright rather than agree by default. The lack of agreement, even without the presence of opposition, might be enough to show that the position is potentially unreliable.

Being a helpful member of a team means working to achieve the same goal as the other team members. It does not necessarily mean following the same process.

Update: Fixed the link to Slashdot. Sorry for that.

My old college buddy asks:

When you are trying out a new development tool, what do you look for to help you learn how to effectively use the tool? Is it help files, tutorials, white papers, samples, case studies, etc? Or do you learn best by participating in classes or through mentoring? Perhaps you only try to learn tools that are easily assimilated, and if so, what makes one tool easier to learn than another?

There’s a saying in the field of User Interface Design (computer and otherwise) that goes “there should only ever be one button: one that does exactly what the user wants.” Of course, this is hyperbole, but it does illustrate the theme of UI design: make the tool as easy to use / simple / natural as possible. A more usable product is the one that the user needs the least amount of thought to use and the least amount of initial training.

Accomplishing this is incredibly difficult, which is part of the reason why most user interfaces are absolutely horrible (the other is that most engineers don’t study usability, especially usability for mass audiences). Fortunately, this is getting better: Apple has made UI a sellable feature, and User Interface Design is now a bona fide field of research that gets attention from the builders (if you’re interested, you can start with Neilsen, Norman, and Tog, the current gurus of usability.

Now, to answer Graham’s question:

what do you look for to help you learn how to effectively use the tool?

Here’s my order of preference:

1. The tool should follow some natural metaphor, if possible. Ideally, the tool should behave as if it is an extension of my body / mind. This way, there’s no learning curve; you already know how to use it. Unfortunately natural metaphors are hard to come by in the decidedly un-natural world of technology, so most of the time this isn’t available. Still, I think it should be said.
2. If tool can’t follow a natural metaphor, then it should follow a familiar one. That is, it should try to duplicate one that already exists. This way there’s zero learning curve for users who already know the preexisting metaphor. There’s two big catches to this approach though:
   1. The old metaphor may not be terribly good to start with. Garbage in usually means garbage out.
   2. The old metaphor may not translate well to the new medium. QuickTime 4.0 is the poster child for this problem.
3. If the tool can’t be familiar then it should be self-describing. The means of accessing the features should be apparent (in fact, blatant). Available features should be displayed (rather than hidden) at the ready. This makes the learning time efficient: you are able to learn while you actually use the tool. A good illustration of this principle is the use of text rather than graphical icons to represent features: text describes the feature far more explicitly and accurately than a (tiny) picture.
4. If the tool can’t be (effectively) self-describing, then it should have description waiting in the wings for the initial learning period. Think of a tutorial, but one that teaches as the user uses the tool. Some modern games are great examples: every time that you encounter a new tool, feature, or technique they give you a brief explanation of how to use it, followed by some time to put it into practice. Play Half-Life or Portal with the commentary on to see the thought process behind this technique.
5. If you can’t do an effective tutorial mode, the next best thing is to have built-in (local) context-sensitive help ready at the touch of a button. There are three important factors to application help: relevance, speed, and connection to other topics (ie: lots of hyperlinks). This will help a user get out of a jam, but it may not do much to get them started in the first place.
6. If local help isn’t available, putting your help on the Internet (say, in the form of a FAQ) is almost as good as local help, although it’s not available if you’re disconnected (ie: on a plane). Internet help also lets you enhance help post-launch and get feedback/usage stats. If you get a good community behind the tool, they can potentially help with the help (with wikis & blog posts).
7. Examples can be useful; lots of people learn better from example than they do from a spec. The major problem with examples though is that they are necessarily of narrow focused and contrived. They may not be answering the questions that are being asked, and they certainly won’t be able to answer every question.
8. White papers and other wordy documentation are not nearly as useful as other forms of instruction; it’s harder to find the solution to a particular problem when it’s floating in a sea of flat text. Always remember that, as a rule, people don’t read.
9. Screencasts are appropriate for dynamic situations, where capturing the actual motion is important. Otherwise, video just becomes a very hard-to-use interface to the information being communicated; think of a book where the pages are turned at a fixed rate. Static text and pictures are better for most applications.

I’ll leave mentoring off my list entirely. I’ve never been a fan of (nor had much experience with) mentoring, because:

• I’ve always had a do-it-myself (and discover-it-myself) attitude.
• I’m often learning at the (b)leading edge of things; mentors with prior experience aren’t always easy to find.
• Likewise, people with more experience are often too busy to spend a lot of time mentoring. They’re adding more value by operating, especially if I’m able to learn effectively without their help (which, in turn, makes me more valuable too).
• I’m more anti-social than most. For work purposes at least, personal interaction is a means to an end, not an end in itself.

These don’t apply to many (most?) other people though, so they’re not a criticism of mentoring itself. Many people appreciate mentoring and find it valuable.

Lastly:

Perhaps you only try to learn tools that are easily assimilated

I certainly prefer easily-assimilated tools. A small learning curve makes the tool more efficient, which is half of the value equation. The other half is effectiveness, and that’s where poor tools can find their niche. If there’s no other tool that can do the work of one with a crappy interface / steep learning curve, then there’s not much choice in the matter; I’ll have to bite the bullet and learn / use it. But I’ll always be looking for a way out.

One stereotype is that teenagers are lazy and carefree, but this study says otherwise:

Canadian teens averaged 7.1 hours of unpaid and paid labour per day in 2005 – a 50-hour work week, virtually the same as that of adult Canadians aged 20 to 64 doing the same activities.

Personally, I felt a pretty big burden lift once I’d graduated college; there was no longer any project or paper looming in the near future which required weekend or evening attention. I now had legitimate time off. It was a wonderful realization.

Paid work is a big thing right now for teens too. Calgary has a tremendous labour shortage going on right now, and most of Western Canada (and perhaps further east) is in a similar situation. With demand for labour rising (taking wages along with it), people who wouldn’t work otherwise are drawn into the labour force… and a big part of that pool is teenagers in high school. I see them all over the place in retail jobs; some look around 14. That wasn’t the case when I was that age; finding a job was difficult (as there were plenty of out-of-work adults with experience who would work full-time for those low-end jobs) so most of my peers and I didn’t bother.

For me, the most distasteful part of the article is this:

Homework was the most time-consuming unpaid activity for teens, with 60 per cent averaging two hours, 20 minutes every day.

When you consider that most homework (especially at the high school level) is unproductive busy-work, this amounts to a huge loss of productivity and an increased stress burden. That doesn’t benefit anybody.

I pose for you a question:

Suppose that a client has contracted you to provide a service. You’re an expert in your field (at least, moreso than the client… that’s why they contracted you after all). The client wants you to perform some action, but you consider this action to be high-risk for the client. You tell the client that this is a bad idea, and that you should take a different course of action instead. The client refuses to agree; whatever their motivations, they insist on following their proposed course of action. Other service providers for the same client are syncophants; they raise no objections. Both the client and the other providers were hit with a problem of the very type you’re trying to avoid just recently… in fact, the client swore to try and avoid it in the future. There’s no guarantee that the problem will occur but past experience clearly says that it’s a bad idea.

Do you:

1. Attempt to save the client from themselves, and refuse to perform the action, even though doing so would make you appear to be a spoiler to the eyes of everyone else involved?
2. Let the client have their way, and play along with the rest. You’re not directly responsible for any failures, but if they do occur, the client may still try to pin the blame on you, and may ask you to work extra hard (at your own expense) to try and fix it.

I got in late last night without incident.

By the way, everyone needs to go and see Pushing Tin if they haven’t already.

I’m in Omaha, Nebraska for a business meeting. This is the first time I’ve traveled for business since I went to JavaOne in San Francisco in 2000.

Getting across the border was uneventful; they didn’t ask me any real questions. The flight was comfortable enough. I flew United this time. One of their armrest-audio channels is the aircraft’s radio; you can listen in to all the air traffic controller chatter. That was pretty neat; Ted would probably freak listening to it.

Omaha (from what I’ve seen at least) is surprisingly pretty, at least at night. There’s tall well lit buildings and a cool-looking stadium called Qwest Center. It contrasts a lot of Denver (all I saw was the massive airport on a huge flat plain; farther out I could see a mass of suburbia). I didn’t bring my cool camera but I have one on my PDA so I’ll try and take some shots tomorrow