Spring Forward. Tally-ho!

How’s the market? I can’t even begin to guess how many times that I have been asked this question. Having worked in and around recruiting for over a dozen years, people assume that I see trends in the labor market that can indicate the overall health of the economy. To a great extent this is true. The companies that I have helped start and run for the past 10 years are proven leading indicators of market conditions, especially for the technology markets: people stop hiring when things get scary, and they start hiring when things look good.

Over the last 10 years I’ve come to the conclusion that downcycles are “light switch” events: you come to work one month and things bright and sunny, the next month they are dark and gloomy. In November of 2000 the recruiting company I worked at started to notice a minor decline in revenue. By February 2001, our revenue was nearly cut in half. By the end of the year, the Dow had lost about 2000 points. In 2008, though this time better prepared, we saw the writing on the wall in the spring as the market tightened and revenue began to fall. By late August hiring had ground to a halt; we all know what came next.

Okay, so ask me “how is the market?” Well, if you follow me on Twitter, you may have caught a tweet last week about my growing optimism. Despite grumblings from some of the guys at my gym (taken with more than a grain of salt seeing as I go to a gym in the Bank of America headquarters), the constant gut-wrenching news from the cable news outlets (who seem to get paid to spread fear), and the worried calls I get from my future mother-in-law (she should get paid to worry), I can tell you that I believe things are on the uptick.

Here are a couple of reasons I am optimistic this spring:

1. In February and March both divisions of GravityPeople, the recruiting company that I co-founded in 1998 are doing really well - seriously. Now, they have great employees that have stayed level-headed and worked hard through what the pundits are calling the worst economy in 80 years, but the numbers are there too. Job orders are up and so is revenue. When I met with some of them today, they told me that they are seeing candidates with multiple offers. This is a really good sign that hiring is becoming competitive again. When hiring gets competitive it means that companies are moving from fear to growth.

2. March has been a breakthrough month for Newton, our recently founded software company. From the looks of it we will start April with several new customers, some press coverage, and some major inertia. Our customers are telling us that they expect to actually see some growth this year, and they’re getting prepared. At Newton we continue to invest in the technology and we are even starting to tackle some marketing projects.

3. The sheer amount of technological innovation that we are seeing in social media, cloud computing, content management, and the mobile spaces, to name a few, confirms to me that entrepreneurs, the backbone of optimism, are alive and well. It’s evident that many start-up companies are taking advantage of a slow sales cycle to innovate and challenge conventional technology and business models.

When I circled around with our teams today, suggesting that I am feeling optimistic, folks seemed to genuinely agree that they too are feeling more positive. In an open discussion we got to talking about all kinds of things like the growing lines at our favorite lunch spots, about the buses that we take to work being more crowded and about it taking longer to get a pint at the pubs after work. By the way, we weren’t complaining, much to the contrary. Social scientists would probably slap some moniker to this discussion and call it collective optimism. But, I don’t care what it’s called.

I am going to call it spring forward optimism and I feel good.

About Email, Twitter, and What I am Doing Right Now…

I think it’s time someone put the bullet in email. I am going to use this post to load the chamber. And once I’ve done that, I’m going to get development working on a project they’re gonna think is crazy.

I’d like to explain myself…

I would guess that, like a lot of people, 95% of my snail mail goes straight into the recycle bin. I’ve actually considered asking my apartment building to put a recycle bin next to the mail box; it would save me a few steps that I can use later for my triathlon training.

I seem to get only two important pieces of snail mail: save the date notices and my car insurance.  In the last 14 days I have received one non-spam piece of snail mail. Snail mail is the de facto the vehicle by which people I don’t know or trust attempt to communicate with me. I will call it a muddy communication mechanism.

Email isn’t much different really. In most cases, I am just saved the time of walking down the fire escape to the recycle bin. Yet amazingly every software application on the planet goes to great lengths to integrate with email. In fact, the single greatest technical ulcer-causer of any software application is Outlook integration. Bar none.

Now, don’t get me wrong. I’m not saying that email integration isn’t necessary at the current moment. I’m just wondering if email’s dual-dominance of both the trusted and muddy communication channels is anachronistic. Why are messages from people and applications I know and trust being dumped into an unorganized file with untrusted messages?

The other day I thought, “Does this still make sense?” (Actually, I was on the treadmill.  After which I ran back to the office, designed a screenshot, sent it to our co-founder, Joel, and texted him telling him to check his email. His reply was, “go home.”)

If you’re like me, you inbox is more like a “what do I do first?” box. I have comments from developers, designers, people trying to sell me things, messages from bike fitters, and most importantly, messages from my girlfriend (which always get answered immediately I might add).

Many of these messages are coming from systems that are trying to boost my productivity: hire people, manage finances, complete projects and track bugs. In essence, my productivity applications are taking their trusted communications (messages I definitely want to read) and dumping them into a message mud bog, then trying to clean them up after I deal with them.  What’s black and white and forwarded all over?

For example, Newton’s bookkeeper, Frances, asks me on any given day,

“Hey, Steve do you know what’s happening with this account? I have one file for 9 thousand users and another for 8 thousand users.”
“I don’t know, let me email Jonathan.”
“Jonathan, what’s up with Huge Company, how many users do they have?”
“They called me the other day. They just upgraded to 9 thousand users.”
“Frances, 9,000. Sorry about that.”

Sounds like we need some Outlook integration!

Email should die. It’s like using a donkey to tow a Tesla.

How did I come to this conclusion?

Well, from a disclosure standpoint I have to admit that integrating with Outlook is really hard and pretty darn scary, and even though at Newton we’re probably going capitulate in some areas, I really don’t want to. Developers of software can control the reliability of their own environment, but once you start relying on someone else’s system you start touching all sorts of things you can’t control.  That’s why every time someone says “integrates with outlook” they never use the words “easily” or “never breaks” or “no plug-in required” in the same sentence. Here’s a simple guide to probably the most integrated outlook application on the planet:  http://tinyurl.com/cf6dae (This is the apparently shorter, “cheatsheet version”).

But, more important to me than the technical hurdles is this nagging belief that email might be the problem, not the solution.

Actually, I’m not even sure it’s the problem. I might just think that there’s a better path to productivity than dumping important messages into an uncontrolled, unorganized inbox and then forwarding them around like crazy, all the while trying to clean, reabsorb and reorganize them back into the system that created them.

Why doesn’t Facebook need Outlook integration? Or Twitter? Is it only because they are consumer applications? Or is it because they are communicating with you by way of channels you already trust?

I think it’s the latter.

I am left to wonder if we should rethink how our business applications communicate with the people they serve. The mail paradigm is not just old, it is centuries old. I can think of some software companies already leveraging clean communication channels, Yammer is an interesting one. I think I I’ll try to build another.  Who knew that Shakespeare didn’t like email?:  “Mud is not the fountain that gave drink to thee.”

Remove Features…

Introduction

This was one of the first Design Philosophies at Newton. Once we got our Home page to where we liked it, to where it was “training-lite”, we made a rule that we couldn’t add anything more to it. The rule was, “Before you can add a button you’ve got to remove one.” This rule has caused great consternation over the years, and for the Home page it has been broken once, and might get broken one more time.

The impetus for the rule evolved from the years we were designing and using other recruiting software systems. Eventually these systems were “improved” into perplexity: at some point so many features were added that the only people who could log in without getting freaked out were people that had used the software for years. Over time, I watched systems like this devolve into rather expensive places to store resumes, and witnessed eye-rolling during training seminars. Call me crazy, but I didn’t feel like walking down that well-worn road anymore.

So here goes, straight from the style guide, another dictum in our Design Philosphy….enjoy.

Before Adding a Feature or Button, try to Remove One.

Understand that the more options you give someone the longer it takes them to make a decision, and the longer it takes for them to learn our software. Instead of adding a new feature, try to see if first you can use it to remove an existing one.

As a designer, you look at the same screens every single day, so you automatically know where everything is and what everything does. Watch a new user login, if they move their mouse around frantically, it means you’ve probably reached overload. Realize this: every button, tab, link, menu, drop-down etc is a de facto question asking the user, “Do you want to interact with me?” And the user must ponder “yes, no, maybe,” for each element.

It seems almost counter-intuitive: fewer choices = faster. Perhaps this is why many software applications have gazillions of things you can do on every page. Problematically, systems like this take a lot of training, and each new feature serves to make New Users more frustrated. If you don’t believe me, try using Photoshop for the first time, without a manual.

Additionally, be watchful of putting power-user features in a prominent location on common pages. Prominency is great for Power Users (who would find them anyway), but New Users won’t know how to use them, so you’ll just flatten this person’s learning curve (or just erase the learning curve altogether).

As a bonus, keeping this rule in mind means that you’ll have more time to perfect existing features, and Development gets to spend more time making our product even more reliable.

There are few things more rewarding than when no one notices you removed a feature.

Think of the Problem, not the Feature

Note: I’d like to point out that this post comes straight out of our design manual. It’s not going to read like a conversational blog post. I figure it’s just better to give you, the reader, the straight skinny.

Always ask “What problem am I trying to solve?” before starting any design.
The first answer you have is at least 90% wrong.
(you’re thinking like a software designer/developer, not a user).

This is the first thing we must ask ourselves before building anything. And, we need to ask this question over and over again at all stages of design, and ask it again after the feature is shipped. Ask yourself, “Is this solving the real problem?” instead of focusing on what the system lacks. There’s a big difference here.

For an example, take our messaging system for rejection letters. Sending rejection letters to candidates is something every company should do, but very few do. In fact, even companies with ATS systems don’t send rejection letters, yet this feature is commonplace. So we ask ourselves, “When designing our rejection letter feature, what problem are we trying to solve?”

The two first-blush answers you might have are:

“The problem is that companies can’t send rejection letters”
Answer: our product lacks this feature OR,

“Sending rejection letters is too time-consuming /people just forget to send them”
Answer: Send them automatically so that they don’t take any time and can’t be forgotten.

But if the above solved the problem, wouldn’t every company with an ATS already send rejection letters? We know that the feature is commonplace, but that they still don’t get sent. Our answer is missing something.

Why don’t rejection letters get sent? There are more answers:

“Sending rejection letters is time consuming and you have to send a lot of them.”
“You don’t want to send the same rejection letter to someone you interviewed 5 times to someone you never interviewed.”
“The perceived benefits (the actual benefits are a different story) of sending a letter are very low, so users will be VERY, VERY, VERY reluctant to spend time doing it.”
“Users don’t trust a system to send rejection letters for their company; they want to read them first.”
“You never want to send a rejection letter accidentally. The risk isn’t worth it.”

So let’s talk about how this feature has been designed and implemented in other software systems. A template is made so that when you pass on a candidate it automatically sends a rejection letter. Does this solve the whole problem? Hardly. This feature only reduces the time it takes to send a letter, but it doesn’t allow for on the fly customization/review, is sends the same letter to everyone, it is generally not trustworthy, and worst of all, it is inherently risky.

To be a complete, helpful, user-centric, REAL FEATURE our system must accomplish all of the following: it must NOT add any steps to the normal workflow; it must customize itself based on candidate status; it must be reviewable before it is sent; sending is optional.

Easy enough, huh? Think of the problem, not the feature.

Intro to Our Design Philosophy

Our Design Philosophy is a set of rules that we apply during our software development process and also to our finished product (which is never truly finished). The goal of creating and codifying our Design Philosophy was to have a set of comprehensive guidelines that are to be followed religiously at all times.

I’ll be posting these mandates individually, and when I get the time I’ll package them up into one web document. I’ll also sandwich in some posts on “Things We Have Learned the Hard Way” which, as you have probably guessed, are things we need to remind ourselves not to repeat.

Disclosure: While my aim behind publishing these is many-fold, I’ll try to keep my disclosure to the point. If I accomplish anything in these posts I’d like you to catch a glimpse of the thought processes that have driven the design of our software. And in doing so, I hope to make it a bit easier for you to appreciate why we believe this thoughtfulness has made Newton the best recruiting software on the planet: the easiest to use, the easiest to start using, and the most productive out of the gate. And we want you to see how our focus on users, not features has enabled us to create a software application that almost anyone can use, from day one, without headaches or hassles, to add time back to their day and cut days from the hiring cycle.

But first, a little background on our design philosophy…

My girlfriend is a Director of Sales at a successful media company (I am not making this up; there is a woman on this planet that can put up with me). Her employer uses a very well-known software application for tracking accounts, customers, leads and opportunities (it’s very likely your company uses it too). Before each and every sales meeting, everyone exports their data to Excel. Why? Because the VP of Sales can’t figure out how to use their sales software.

Does this software need more features?
(BTW, I just broke an edict of Newton’s Design Philosophy by asking a stupid question. Good thing I’m not designing software right now.)

As the person responsible for the design of Newton, I’m always looking at products and asking myself questions like that. My ears are ringing. Your ears might be ringing too.

Where’s the noise coming from?

Feature cacophony.

It’s no small secret that software companies are under tremendous pressure to build more features. It certainly seems logical that if you have the most features, you’ll sell the most software (it also makes those checkbox “Us vs. Them” charts on your website look really long and cool).

Unfortunately, I think a lot of software, and especially ATS software, has lost focus on the most important feature of them all: users.

You say, “Users aren’t a feature, smarty pants.”

Hmmm. If a tree falls in the woods…If no one ever uses a feature, is it a feature?

I ask this because I would bet that if you’ve ever hired someone, you didn’t want to use software to do it. Maybe you were forced to use it and thought of mutiny.

I’ve witnessed this first hand: people in a hiring role hate using software for hiring. But in all my years I never heard someone say the reason the hated the software was a lack of features. Not once. In my case, I’ve used a lot of different recruiting products over the years and I’ve learned they ALL do one thing very well: they make hiring harder for everyone. The software you need to be forced to use makes you less productive. Brilliant.

Obviously when people can’t, don’t, or must be forced to use software you’ve developed you have a problem. The seemingly obvious solution to this particular problem is to build more features-innovations a mile wide, an inch thick.

Problem solved?

This line of thinking brings us to the first rule in our Design Philosophy-

Always ask “What problem am I trying to solve?” before starting any design.

In our industry the problem we’ve identified is that recruiting software doesn’t make it any easier, simpler or faster to hire someone, and most people don’t like using it.

Our solution: Focus on building software that boasts a lot of users, not a lot of features.

The user is a feature.

Enjoy.

PS. Hello World!