The Unbearable Lameness of (Certain) Recruiters

Now before I get too far into this, not all recruiters are bad, shifty, underhanded, manipulative and entirely quick-buck-oriented and self-serving (and several less polite things I can think of), but I am occasionally amazed at the snake oil quality that many bring to the table. Here's an email I got today:

Hello Loren,

This is XXX following up with you in regards to this exceptional candidate. I do feel strongly that he would be a great asset to your team at Alexander Interactive. Again, his key points are:

If you are interested in this engineer or top recruiting services, follow up with me at your earliest convenience. I know you would be very impressed with the level of service and candidates we provide to our clients.

Please feel free to refer to our website for more information and call me at the number below to discuss your technical hiring needs in detail.

Best,

XXX

So in no particular order:

• This is obviously a boilerplate letter - both from the hokey tone, and the fact that it says "key points are" without any actual key points listed.


• This also indicates that the recruiting individual didn't bother to check his letter, meaning that he isn't that interested in what I may actually want in a candidate.


• The subject line was "Surprised I haven't heard back as yet; do you have time today?" What? I'm shocked, shocked that I didn't drop everything to look at your candidate that I didn't ask for, that we've never spoken about, that you selected randomly from the stack of resumes in front of you and decided to push on me.

Recruiters, read this next part. Read it well:

• I only work with recruiters that bother to listen to what I want in a candidate.
• I never schedule interviews without looking at resumes first. Ever.
• If you don't hear back from me about a candidate, it means I'm not interested. Period.
• Recruiters that annoy me, by acting manipulatively, by trying to "trick" me into scheduling an interview, who try to mess with the other staff here in an attempt to get to me, who constantly call but never leave voice mails - these go onto a blacklist. The entire recruitment company, not the individual agent. There is no way off the blacklist.

Generally I find that recruiters subtract value from the equation. Besides making hires more expensive for us, they generally act as a kind of contrary indicator about candidates. Good developer candidates don't need recruiters - they go straight to Craigslist. On average (and yes there are exceptions) the value of candidates from Craigslist is head and shoulders above the value of candidates from recruiters.

So if you are a recruiter - be the exception to the rule. Listen to your clients or potential clients. Don't play games. Or don't "be surprised that you haven't heard back from me". I'm ignoring you.

IR Design 08, Ai and Twitter

For the rest of this week I will be attending the Internet Retailer 2008 Web Design Conference in Miami. I'm looking forward to it. The agenda looks very good, and so does the weather.

I will be twittering my thoughts during the conference. Feel free to follow along. The link above is to the Ai team; you'll hear from our president and creative director, also in Miami, plus random thoughts--very random--from my coauthor Loren Davie and other Ai employees in New York.

Layers

Seth Godin: "We live in a layered world now. Those that plan and plan and then launch are always going to be at a disadvantage to the layerers."

So true, and "now" doesn't just mean "of late." Web professionals have long promoted the fluidity of their work. It's the beauty of the thing: one can always redo, change, expand, improve. Some lament the constant beta status of startups, but the evolutionary ability allows them to succeed.

Within this context, of course, one has to look out for the "good enough" trap. Is the project really good enough to launch? If so, put it out to the world. If not, don't rush into it for the sake of existing. Make it good, not good enough. Then stick it out there, even if it's missing the 38 features that are supposed to be in the final release phase.

Layering and iterating allows the potential audience to help define it. This is not just important; it can be career-altering. Flickr was a game until the image-posting app became too powerful to ignore. Hummers were military vehicles until Arnold Schwarzenegger asked AM General to make him a civilian model. Layering on multiple models, features, and ideas led these companies to successes far more vast and different than originally proposed.

So get that launch out the door and see what happens. Add layers as time allows and as market needs demand. And be willing to change course. It's not just the layers--it's the minds behind it that help dictate the success.

Search Design

How do you find the information you're looking for on the Internet? This, of course is the original reason the Web was created - as a publishing platform for the physicists at CERN.

As the web matured, people constructed websites with tree-like structures, viewable as a site map. As web sites grew in size and complexity, we started referring to a large amount of information organized in a tree structure as a taxonomy. Some people (I'm looking at you, Yahoo) tried to taxonomize the entire web. Here's what we found out about taxonomies: they don't scale. Once they get too big, they start to collapse under their own weight. Historically it was a mark of a professional that they could navigate a large taxonomy, such as the Dewey Decimal System, or Scientific Classification. I don't believe that we'll see many new taxonomies of that scale adopted by the world at large.

So that leads us to search. Search, of course, is the other method we have to find the information we're looking for, especially when all we want to do is get to the information, and we don't give a rat's hiney how it's catalogued. But since the average search length on Google is something like 1.3 words, we need to infer a tremendous amount of information from very little input.

To me, this seems like a tremendously deep opportunity for the developers of websites to shape how information is presented via the establishment of business rules modeled within search. I call this Search Design, and I see it as a critical part of how websites with large volumes of information should be built.

Search design is currently implemented primarily in terms of how information on a website is indexed. This indexing controls the relative importance of information, and the relative importance of different structures inside the information, and is generally implemented by the developers who built the website.

However, at a higher level, search design is something that can be expressed as a series of business rules. Say you have a newspaper site with articles and authors. You could establish the following business rules for search:

• Articles have higher priority than Authors
• Weight of an article should be, in order of priority: Article Title, Article Author, Article Tags, Article Body.
• Weight of an author should be: Author Name, Author Department, Author Tags, Author Bio

It could be a lot more sophisticated than this of course, it could contain relative numeric values for the indexed values, and the business rules surrounding relative importance of information could also be far more sophisticated.

Search scales. It can handle a LOT of information, but as implemented on individual websites, the presentation of it to date has been relatively naive. Search design could grow to be a profession in itself, much in the same way that information architecture developed over the last decade. For many sites it is search, not a taxonomy structured navigation, that is the primary means of navigation for a website.

Pricing right

A fascinating study was released last week that observed people find expensive items more desirable simply because they're more expensive. The same bottle of wine is more appealing to consumers who believe it's worth $90 than others who are told it's worth $10.

Pricing reactions also rely on contextual cues. Panasonic has found midprice items sell better when shown next to pricier models. The "reference prices" around a product significantly affect their perceived value.

These discoveries are not really new. Consider the make-up artist my wife hired for our wedding five years ago. After agreeing on a price, he forgot what they had decided, and quoted a second rate 80% higher. When my wife expressed shock, he quickly reverted to the original price. He explained that many of his clients were upper-class women who wouldn't think he was as good a stylist at the rate we were paying. Raising prices actually appeals to his audience, the cost verifying the talent on offer.

These theories are particularly interesting with regard to online merchants. As noted in the New Yorker article, websites create price transparency, which makes for savvier consumers both online and off, and forces retailers to compete in other ways.

The most intriguing question is raised by reading the two articles above as a single unit. In the first, The Economist argues that prices create emotional response, which could be used to sellers' advantage. In the second, James Surowiecki suggests almost the opposite: that the Internet has eliminated much pricing opacity, creating empowered consumers who understand right-priced items. Observing which one proves more accurate--or whether these theories work in parallel--will help define a generation of sales strategies.

Your Agile Process Sucks

I am so sick of people throwing the term "agile" around like some sort of magic pixie dust that can be sprinkled on projects, making them somehow robust, easy to build and otherwise wonderful. Like any popular idea, it has been hijacked by the same people who screwed up permission marketing, business process reengineering, and other things that started out as good ideas.

It's just a hammer - it's only good for nails. Not everything is a nail. There are two really irritating things going on:

1. Ideas have boundary conditions. They're not randomly good for everything, they always have sets of conditions under which they work, and sets of conditions under which they don't work. Agile is not appropriately applied to every case.



2. People throw around ideas they don't understand. "Agile" generally refers to a group of software development methodologies, including Extreme Programming, Scrum and Crystal. These processes do things differently from each other, and just saying "Let's do this agile" doesn't mean a whole lot by itself.

Just Because It's Best Practice Doesn't Make It Agile Let's build stuff in iterations! Yeah, that's agile! Uh, actually the concept of iterations somewhat precedes the whole agile thing - they just adopted it because, well, it's a good idea. Also items like code reviews, version control and a lot of communication with the client are not uniquely agile, they're just ways that we've learned are a good way to build software.
Calling it agile doesn't make it so To truly build something in a lightweight manner takes commitment and courage. Things like having small, quick releases, a flexible scope, little or no documentation. Far too many people throw the "a-word" around their developer process and then settle back into their 2000 pages of documentation.
Agile is not a business plan The grass is always greener on the other side for disciplines. Software developers (for some reason) seem to wish they were architects, so they steal concepts like "design patterns" and "information architecture" - trying to capture the architect mojo. Business, in turn, steals from tech - speaking of management concepts in terms of "bandwidth" and, yes "agile". To say "we're an agile business" is meaningless, and borders on intentional obfuscation - its an attempt to appear hip without actually making a commitment to any specific practice. Much like using the word "impact" as a verb, the easy mis-use of "agile" by people in the practice of nothing particular moves the term itself, which was sort of useful at one point, to a state of complete meaninglessness. I have to suppress the urge to snicker every time I hear someone flinging the magic pixie dust around. Maybe I'm allergic to it.

Next-gen ecomm

From our flu-infested president (and reluctant blogger) Alex Schmelkin came this email last week:

I'm lying in bed with two horrendously uncomfortable pillows. Down feather nonsense. Popped onto amazon. Found the cheapest synthetic pillow. $9.99. Cart. x2. One step checkout.

The amazon ecommerce mobile site is phenom. It's fast. Super easy. Recognizes you're coming in on a mobile and serves the correct pages. Login in. Has all your addresses and credit card. Search. Checkout.

Alex sent this email to the team as both a cajoling boss and an impressed consumer. Lying in bed, playing with his BlackBerry, he went dit-dit-dit through the world's largest online store and completed a transaction as easily as he'd send an email.

This is the future of ecommerce. It's already happening in Asia, and it's a matter of time before it gets here, spurred on in part by the iPhone. Simple, clear mobile interfaces. Fast-loading pages. No-nonsense engines and processes. Nothing but goal-oriented transactional functionality.

Look for much more of this in 2008 and '09. And try it, too. Usage drives evolution.

SAS, Outsourcing and Business Risk

Update:  This post has nothing to do with these guys.

I have long been a fan of outsourcing (not necessarily offshoring, which is a different animal).  Take the stuff that's not the core of your business and move it off to those who are experts in it.  I think it gets even better when that service can come through a nifty lightweight web 2.0 interface.  In other word, Software As a Service (SAS) UPDATE: Sorry - this should actually have been abbreviated "SaaS". Acronym fixed in the rest of this post.

So, along those lines, we here at Ai use a number of web-based outsourcing services to handle our non-core activities.  We use BaseCamp as a collaborative project management tool, and Harvest for time tracking, to name a few.  These decisions are cost-effective for us, because we're not in the collaborative project management tool business, nor the time tracking tool business.  We build websites for clients.

There's a catch, however (you knew the catch was coming, didn't you?).   There is a question of risk for each business function that is outsourced to a SaaS.  This risk can be difficult to quantify, so it can be a bit much for the more risk-averse business people.

SaaS-related business risk generally falls into two categories:

• Availability:  How often does the SaaS go down, and become unavailable to its clients?  Depending on the level that business depends on the SAS, lack of availability can have a serious business cost, usually taking the form of paralyzing the business in some way.
• Data Loss:  Much worse than availability, when mission critical data is put into an SaaS, data loss can be deadly.  Data loss can kill a business.  Dead.  A less deathly, but still damaging variant on this is vendor lock-in, where there's no expedient way  to leave the SaaS, because all of the business' data  is in the SaaS system, with no way to export it. 

Am I being hyper-cautious?  Are these risks just hypothetical?  Well, in the last week BaseCamp (actually all of the 37 Signals apps) went down because of a bad router.  There was no backup router in the rack, apparently, meaning that the entire suite of SaaS apps from 37 Signals had a single point of failure which, well, failed.  For all of Friday morning, no one derived any benefit from BaseCamp.

Last week Twitter (admittedly not the first thing one thinks of for business-facing SaaS, but still...) died unceremoniously during the Steve Jobs Macworld keynote.  Too many Apple fans live-blogging for Twitter to stand, apparently.

These risks slow SaaS adoption.  In order to make the leap across the chasm from early adopter types to the majority, SaaS providers must find a way to mitigate these risks.  This kind of thing  will be tolerated by a certain breed of early adaptors, but the more  conservative majority need more assurances.

Hello, SaaS providers - I'm talking to you now:

1. Service Level Agreements for SaaS:  How about an uptime guarantee.  That is typically followed by an investment by the provider in the technical infrastructure to provide the agreed upon service level.  Like backup routers.
2. Data backup and export:  Some assurance that a) our data is safe and b) we can get it away from you would go a long way to mitigating fears of certain business death in the event of a technical failure of an SaaS, or should we decide that we want to switch to another SaaS.

Now I'm not asking for regulation or anyone to pass a law or anything.  But it would be nice to have a certifying body out there somewhere for this kind of thing - a "Hacker Safe" for mitigating SaaS business risk.  That would provide businesses the assurance they need, and allow SaaS to fully cross over into the mainstream.

Accessibility design

Many members of our team love 1024-pixel designs. So do many of our clients. And why shouldn't they: the real estate is vast, giving room for airy designs that fit lots of information above the fold. The results support their desires, too; our websites are uniformly handsome and easy to use.

Unfortunately, the average user doesn't have the same 30" cinema display as our creative director. (Alas, neither do I. But I digress.) Visitors to Ai's sites are mostly in the 1024x768 camp, but narrow displays appear on a regular basis.

It can be easy to disregard these folks, to say, "Ah, well, the guy in Jersey with his screen set at 800x600 because he doesn't like to squint, he can scroll to the right, lots of other sites make him do it." What's not so easy is to imagine the financial pain that could come from ignoring them. This forces us to be even more creative with our designs.

Thus our information architecture and graphic design teams ensure that all essential functions of the website appear within that 800px window, from major navigation links to add-to-cart and checkout buttons. Imagine the chaos, not to mention the customer service inquiries, if those smaller screens had to scroll right to hit "continue." At Ai usability and accessibility are of prime importance.

In my days as design director at Economist.com, we set a tiny three percent limit on browser compliance. (This was back in the Netscape-versus-Internet Explorer days, as we debated dropping Navigator from our QA routine.) As I liked to cite to our tech and ad teams: "Three percent sounds like a small number. But 3% of a million is a pretty big number."

These variables are what make web design difficult, and fascinating. Accommodating myriad screen widths, several popular browsers (currently IE, Firefox and Safari), two major operating systems, and layering on mobile constraints--consistency is nearly impossible. What's important is a solid, confusion-free user experience that works regardless of a visitor's variables.

One of my small contributions to Ai is championing the minority. Our websites already reflect the core values of universal user experience. The challenge is in pushing ourselves farther into universality with every site we make.

The Day The Twitter Died

8:45 PST:  15 minutes before MacWorld Keynote begins in San Francisco.  Everyone hops on Twitter to liveblog the event.

8:46:  Twitter crushed, collapses in a smoking pool of molten metal.

What's Privacy Worth?

What is this thing "privacy" that we seem to be in constant peril of losing?  In Europe it seems to be treated like a sacred substance, with various laws protecting it.  In America it has significantly less value, being signed away by private citizens to corporations hungry for consumer data, without a second thought.  What is it, exactly?

I think there are probably a couple of components to privacy:

1. Information: Meaningful data about someone.  Some information we're only to happy to push out to the world as environmental spam: the car we drive, the house we live in, the brand of shirts we wear.  So the existence of information by itself doesn't constitute privacy.  There's an additional component.
2. Restricted Access:  Not just anyone can get all of our information.  Some of it is private, and can only be accessed by the appropriate individuals.  We have different ways of categorizing access - for example we pretty much hand the keys to the kingdom for our financial information over to our accountants, but probably wouldn't tell them everything (or anything, necessarily) about our health.

But still there's more.  The real truth is that most of what is controversial these days about privacy has to do with observation of our behavior.  Where did we shop?  Where did we surf?  What did we buy?  What are we likely to buy?

Ok - this kind of information is valuable.  And in our society we have a mechanism to deal with the transfer of value from one party to another.  Its called "money".

Show. Me. The. Money.

How about this - lets create a trade unit with which I can distribute my privacy.  A "consumer behavior credit".  A credit is defined as:

• The right to my observed behavior,
• For a specified period of time,
• Within a specified scope,
• For a specified use.

So for example, I might grant you the right to watch me surf around on amazon, spending way too much on books.  So I could sell, for fair market value, 1 day of me surfing book websites, for the purpose of channelling advertising to me.  $5.00 please.

Lets make it easy.  A marketplace for consumer credits.  OpenID style.  I (the consumer) sign up for credits, and set business rules under which you may observe my behavior (for $).  Perhaps I can have "personas" which allow me to separate "Business Loren" from "Fun Loving Guitar Phreak Loren".  Then, a website that participates in the program can happily harvest my information, sending me compensation for it, and use it according to the terms of the license.

You get your information, and I get compensated for what my privacy is worth.

On direct marketing and user experience

Usability maven John Rhodes published a clever piece last week entitled How Direct Marketing and User Experience Are the Same. The cited examples are quite good and worth contemplating (Rhodes is often right when it comes to UX matters). Particularly for ecommerce sites, the direct-marketing correlation is strong.

Something the article did not do, though, was reverse the angle. The piece focused on how the technical details of UX work are similar to the fundamentals of direct marketing. But direct marketing also has a lot in common with the qualitative side of user experience work. To wit:

• Simple, clear instructions maximize conversions. In any direct marketing appeal, the endgame is straightforward and easy to spot--as with the majority of UX-centered processes.
• First impressions are lasting impressions. Consumers decide in seconds whether they have a good or bad feeling about a product, company, or website (especially a website). Similarly, a good piece of direct marketing leaves consumers with a positive feeling that either leads to a sale or is retained until a later conversion opportunity.
• Understanding and relating to the end user is key to long-term success. Like a good website, a good direct marketer will fine-tune and localize messages over time, creating a more intimate and useful dialogue that leads to greater response rates.
  

One aspect that may not be the same is the value of the individual viewer. A user-experience expert would cite the necessity for all users to have as positive an experience as possible. Conversely, some direct marketers are looking for scale above all else, and are unafraid to sacrifice some people in order to reach others effectively. This is good for short-term sales, somewhat less so for customer retention and positive recall. Which, of course, is where UX comes in.

Sabbaticals At Ai

We're trying something new (for us) here at Ai - sabbaticals.

For approximately three weeks at a time, we're sending smart people out of the office to do something fantastic of their own volition.  They call the shots on the project scope, the approach, the technology and the working methodology.  We make an enormous effort not to bug them during that time.  When they come back they've built something cool.

We decided to do sabbaticals for the following reasons:

1. We wanted a mechanism to allow self-directed projects.  Normally this is very hard in an agency environment, so we needed to create a mechanism that isolated the people from the mainstream agency.
2. We wanted to create assets that would either be the basis for possible future projects, re-usable components, or open source projects that we could sponsor.
3. We wanted to reward proven performers with an opportunity to work on something especially fun.

We thought carefully about how we could do this.  What we came up with was a program where people could write proposals for their sabbaticals and then work from out of the office in order to fulfill them.  The sabbaticals are about 3 weeks long, and can take almost any form.

The people on sabbatical are mostly offline to the mainstream of Ai.  They check their email only once per day, aren't on IM and only respond to emergency phone calls.  We leave them alone to work.

Our first sabbatical is being taken by two of our senior developers - they are blogging their progress so we can see what's happening in their world every day.  Its also a pretty interesting blog, IMHO.