Bureaucracies temporarily reverse the Second Law of Thermodynamics. In a bureaucracy, it’s easier to make a process more complex than to make it simpler, and easier to create a new burden than kill an old one.

Now, I'm no physicist, but it seems pretty clear to me that bureaucracies absolutely obey the second law of thermodynamics.

"Process" isn't anti-entropic at all, any more than gasoline-powered engines are anti-entropic. The process itself, the bureaucratic imperatives, are entropy and waste heat. Which isn't to say that you can perform useful work without a certain amount of process, or that certain applications don't require an enormous quantity of process. A good startup is an efficient engine, generating lots of results with a minimum of process. A good large organization is less efficient, but trades that efficiency for reliability and consistency—it's a big rig, with a big diesel engine, or possibly an industrial motor of some sort.

The 20-city slice of the S&P/Case-Shiller Home Price index recorded a drop of 0.6% from March to April, compared with a 2.2% drop in the prior month. The index has declined every month since July 2006.

The problem is, as Seattle Bubble is fond of pointing out, there's normally a bump in housing prices from March to April due to the seasonality of home sales.

A more fair comparison would be comparing the year-over-year price changes from March and April. The Wall Street Journal reports that the 20-city index reported a year-over-year decline of 18.7% in March, and The New York Times reports that the 20-city index reported a year-over-year decline of 18.1% in April.

The numbers CNN reports sound as though we saw a 72% improvement, but once you remove the seasonality and look at the year-over-year numbers, the improvement is only 3.2% better. That's quite a difference.

And in either case we're looking at a second-derivative number here: the change in the rate of decline. We're still talking about a very significant decline, which appears to be ongoing. Even if we see a few months of positive changes, Japan saw several multi-month periods of positive improvement in their housing market before it bottomed out.

The actual headline was Economists: No global collapse in '08.

The reason nobody published the "Alien annihilation of Earth not expected" headline is that the possibility isn't on the radar of anyone reputable.

Draw your own conclusions.

Last week, I presented at SASAG on this topic. I've made my presentation on Professionalizing Technical Support available here; it's still a PowerPoint document. Please let me know if you'd like this data but require a different format. The extensive notes, of course, represent what I wanted or tried to say, not what I ended up actually saying. (Like any good SAGE meeting, the presentation was much more a discussion than unidirectional transfer of information and ideas.)

Read on for my impression of the meeting.

• People agreed that there existed concerns shared by technical support staff, and seemed to accept the notion that Technical Support was a semi-independent field that might deserve professionalization. (Nobody argued that it was just one part of being a system administrator, for example, even though many system administrators perform technical support.)
• People recognize that Technical Support is the face of IT, and it’s important.
• People accepted the claim I presented (based on a summary of the Jonassen paper referenced in the presentation) that the best predictor of troubleshooting ability is experience; somebody who has spent more time troubleshooting performs better than someone who hasn’t, even if the latter person has more theoretical knowledge.
• People recognize that Technical Support is typically staffed by very junior people, because the job is not widely considered desirable.
• People recognize that the inexperienced people typically on the front lines of technical support damage the reputation of the entire technical organization: they frequently lack the customer management skills that more experienced technicians have developed, and often do an objectively poor job due to a lack of experience.
• People seemed to accept my contention that the best solution would be to make technical support a desirable career; however, people seemed somewhat skeptical that this was achievable.
• Reasons that this wouldn’t be likely revolved around three major points:
  • Money: people can make more money in Sales, Management, and even in Development. This was the most frequently (and vociferously) argued point.
  • Accomplishment: the frequent recurrence of many problems across different customers (or even with the same customer) leads to a sense of futility. Unlike project-oriented work, technical support staff rarely get to stand back, look at a completed piece of software, and say, “I did that.”
  • Predictability: many technical people prefer situations where they can set their own schedules (even if they have to work more), with fewer fire drills and screaming emergencies; technical support offers many fire drills, screaming emergencies, and lots of talking with unhappy people.
• People seemed willing to entertain the notion that somebody, somewhere should work on professionalizing technical support.
• People agreed that mentorship was the primary vehicle for socializing new technical support engineers, and even argued that mentorship was how law students, doctors, system administrators, and other professionals learned their jobs.

There are no strict action items at this time. I’m trying to decide whether it makes sense to try to hold some kind of in-person meeting for technical support professionalization in the Seattle area, if this concept should be presented in person in other contexts (ie, at conferences and other local technical groups), or if it can be successfully pursued online.

Before determining if some sort of group makes sense, I imagine that I’d need to develop some explicit agenda items for that group. Obvious candidates include a forum for presenting and discsussing case studies of how people are performing technical support; case studies of mentorship and training programs; discussing and refining troubleshooting methodologies; and promoting development of technical support as a career rather than as a stepping stone a different career in Sales, Management, or Engineering.

I'm extremely interested in talking to anyone who has ideas, wants to contribute toward moving this forward, or strongly disagrees.

I'm in tech support, and I love my job: I love helping people solve problems, and I love working on the tricky things. I like working on streamlining processes to reduce support effort, I like figuring out how to communicate internally and document our processes. I even get to do a little bit of writing scripts for internal use and to solve customer problems that, strictly speaking, shouldn't be our problem.

That said, I often feel like I'm making it up. I feel like my management's making it up. And I don't think that's their fault, or mine.

It seems to me that even the biggest players fail to provide adequate tech support, and so when Joel posted Seven steps to remarkable customer service, I nodded my head more than I usually do while looking at blogs.

It sounds like Fog Creek Software solves the problem in a way that only smaller IT shops can; I don't think their techniques could apply directly to life at Dell, or even where I work. But the ideas are important for all tech support shops.

A number of people have done awesome work on professionalizing systems administration; The Practice of System and Network Administration is an example of that. Where's the parallel effort to professionalize tech support?

On a technical level, working on troubleshooting techniques or considering a debugger's-eye view of particular subsystems would make great conference tutorials and presentations. I could certainly use a course on reading SMB packet traces as a means of troubleshooting filesharing issues, or on putting together flowcharts that tier 1 engineers would find useful. (If I'm Mac-less, but have access to Windows and to Linux, is there a better way to do this than Visio? What kinds of notations does experience show are used by Tier 1 folks, and what kinds don't work as well?)

Figuring out how to communicate across shifts in a 24-hour shop with multiple people on each shift, and how to appropriately schedule people, are things that everyone seems to have figured out in their own way. However, a lot of that seems to be "this worked at my last shop, let's try it here" and "it's not great, but I don't have any better ideas." Having people present lessons learned from their own projects or shops might improve results for all parties.

Knowledge bases are another great topic; I'd like to see product comparisons and case studies, from search results to see how these tools get used, how to entice engineers to contribute, article templates that produce different levels of responses, and so on.

I've done my Google searches, and I'm not seeing the conferences, journals, books, or blogs for professionalization of technical support. Given that support is a huge cost center for many businesses, and given that it's difficult to determine best practices for the field, it seems to me that someone should probably do something with regard to this.

I'm happy to give of my copious free time toward results in this arena.