Hiring Innovators 101

In the final stages of spinning down Churnless (January 1st, here we come), I’ve received a steady trickle of job offers for February, after I spend a month catching up on sleep and doing a whole lot of product advisement that I promised to various folks over the years.  But there are some companies I’d particularly love to work for and some jobs I’d particularly love to do, so I still fill out job applications occassionally.

Which leads me to the following note to all executives everywhere: if you want to hire more innovative people, make your job application process less painful (lower inhibiting pressures; dual proess theory at work). Companies are constantly bemoaning the lack of talent available to them and how much it takes to buy it, but attracting good talent isn’t always about throwing money around.

At the most basic level, just improve your technology. IDEO has one of the worst job application websites I’ve seen. Ditto JetBlue. Even Google, a profoundly tech company, has a shockingly bad UI when it comes to applying. All three are innovative companies who could potentially become even more innovative, if finding good fits wasn’t quite so painful.

It is about more than just appearance, though most sites do look sadly like a bunch of forms pages from 2001. The actual functionality of the site: whether you can submit a prepared resume or have to retype it into a plain text box. Yes, I know you want to be able to use automated parsing to run matching algorithms and keep info in a database, but by forcing applicants to adjust to you instead of meeting them halfway, you guarantee that some number of truly talented people will give up and simply go work at a local startup that they can walk right into and get hired on a handshake and a resume in whatever format best expresses their background.

And if you do need structured data, please just let me import it from LinkedIn. Unless they are your absolute direct competitor (and probably even then), we’ve all pretty much agreed that LinkedIn is going to be the professional directory for now and in the same way that sites accept .doc uploads even if they hate Microsoft, it is time to let me import.

The three tips version:

  1. Allow people to upload resumes in multiple formats.
  2. Make your jobs website visually and philosophically fit with your brand (not just your position listings but your whole application process).
  3. Import LinkedIn if you absolutely need structured data.

Opposing Forces Theory

This is one of those posts that I’m mostly writing so that I can repetitively link to it whenever I use this construct, so I don’t have to keep explaining myself over and over. As such, it is one of the few posts that I’ll likely edit, so if you see changes, I’m just trying to make sure I’m accurate and complete.

Please note that this is all just a summation of research done by a number of smart people over a great deal of time.  I’ve tried to explain it as clearly as possible, but the real credit is with the social psychologist, economists, and others that have worked on it (and who are too numerous to name).

Opposing forces (or dual process) theory is my psych shorthand for a powerful but relatively simple way of understanding human behavior. Speaking in sweeping generalizations, all decisions and behaviors are the the product of two fundamentally opposing sets of forces: reasons to do something (promoting pressures) and reasons not to do something (inhibiting pressures). These can be internally or externally generated, and how receptive you are to internal vs external cues can itself be acted upon.

The reason this is such an important concept in behavioral change is that if you want to inspire a particular behavior that is not already occurring (or make an existing behavior occur more or less frequently), you start by understanding the balance of forces behind the current state of the world. Once you know why people are doing what they are doing, you can figure out whether you need to remove obstacles or place more in the way, or make something more or less rewarding.

Generally speaking, I see companies (and non-profits and the government) leap towards promoting explanations much too quickly. Want people to eat healthy? Most programs are about telling people why it is important (promoting pressure). But the answer most likely to yield results? Make healthy food cheaper and easier to get (inhibiting pressures). Most people love strawberries (they already have plenty of promoting pressure) but not when they cost three times as much as a bag of pretzels and are in terrible shape at your corner bodega.

Bugs (and how to talk about them)

This is potentially the greatest thing I’ve seen all week (partially because I’m currently facing a Mandelbug).  How a team handles bugs is a strong signal about its overall cohesiveness and quality, and for any product person, there is a lot of personality management that goes into bugfixing.

Technically, a bug is a mistake.  But what people forget is that it isn’t always a programming mistake; product people are equally at fault if the issue is that they didn’t push the product far enough or specify edge cases.  So dealing with fixing bugs is an art: you have to get it done quickly and effectively (which means finding our where the problem is) but avoiding letting blame casting get in the way of actual fixing.

My product person approaches:

“A bohrbug (named after the Bohr atom model) is a bug that manifests itself consistently under a well-defined (but possibly unknown) set of conditions.”

So one of two things happened here.  One, you documented the behavior you wanted and the engineer didn’t make it happen, in which case you nicely say “Hey, this doesn’t seem to be behaving to spec, it should blankedy blank blank.”  Two, there exists an edge case (or regular case) for which you didn’t define behavior so the engineer made something up (or did nothing at all), in which case you should immediately apologize and get back to speccing.  “I never even thought about that possibility.  Sorry about that, yo; let me go noodle on how to fix it.”

“A mandelbug (named after fractal innovator Benoît Mandelbrot) is a computer bug whose causes are so complex that its behavior appears chaotic or even non-deterministic. This word also implies that the speaker thinks it is a bohrbug rather than a heisenbug.”

These bugs are the most likely to provoke an argument.  Take, for example, my week.  Two people at client can reliability reproduce the bug (and take screenshots of it) but since I’m not there, I can’t actually see the error.  And neither I nor the engineers, using same OS and browser and version, can make the damn thing break.  It is tempting to tell the client that they are insane or doing something wrong, since the code itself is static: in theory, what it does for me, it should do for them unless they are fundamentally misbehaving.  The key product challenge here?  Accept that other people are probably not as crazy as they appear.  You have to accept that the bug exists, though you can still choose whether or not to fix it.  Which you may very well choose not to, especially if it only seems to occur for one in every million people.  “I totally believe that you’re seeing it, I just can’t reproduce it, which means I can’t fix it.  I’m going to try something on this end…did that fix it?  Nope?  OK, maybe this…still no?  Alright, since it seems to happen only to you, until we get back some other reports so we can figure out where it is coming from, we’re going to have to just let this one go.”

“A heisenbug (named after the Heisenberg uncertainty principle) is a computer bug that disappears or alters its characteristics when an attempt is made to study it.”

It only sort of counts, but I often see these happen between QA and Prod, where theoretically nothing is different and yet the bug seems to appear only on Prod.  You clearly can’t test the code on Prod, so you need to test it on QA, but it doesn’t break on QA, so…you quietly go insane in a corner.  Again, rather like a mandelbug, the product person’s role here is to keep everyone calm, act rational, and not let the inherent insanity of the bug infect people.  “Hmm, OK.  Let’s not worry too much about why things are operating differently here, and just try to deploy a fix to QA  As long as it doesn’t wreck QA, we’ll deploy to prod and see if that fixes it.  Preferably at 3am, so we can revert if this gets worse.”

“A schrödinbug is a bug that manifests only after someone reading source code or using the program in an unusual way notices that it never should have worked in the first place, at which point the program promptly stops working for everybody until fixed.”

This bug also frequently makes people feel insane.  “The link isn’t turning blue.”  “It wasn’t meant to turn blue.”  “I feel like it used to turn blue, I swear.”  “Well…do you want me to make it turn blue?”  My best advice?  Just decide what you actually want it to do and make it do that; let history be history.

“The phase of the moon bug is sometimes spouted as a silly parameter on which a bug might depend, such as when exasperated after trying to isolate the true cause.”

This is more of a bug game then an actual bug.  If you have, for example, a mandelbug, it is often amusing to try to figure out what could possibly be different between two environments to cause the issue.  I’m blaming mine on the fact that they are in Kansas City and therefore covered in BBQ sauce most the time.

“The term alpha particle bug derives from the historical phenomenon of soft errors caused by cosmic rays.”

We’ve sort of reclaimed this one in my experience to mean “any bug that happens only a couple of times, then mysteriously fixes itself”.  Best advice?  Let sleeping dogs lie.  There is a temptation to rip in there and try to figure out why you saw it those few times, but really, shouldn’t you be building something else?

Entrepreneurship (the country music version)

You got to know when to hold 'em, know when to fold 'em,
Know when to walk away, know when to run.
You never count your money when you're sittin' at the table,
There'll be time enough for countin' when the dealin's done.

Oh, Kenny Rodgers (actually Don Schlitz, but whatever).  In the chorus of The Gambler, the old timer lays out what are basically the rules for being an entrepreneur, which is as much about timing as it is about anything else.

I don’t want to suggest that I think business is like poker, because I think that attracts the wrong kind of people to it, those who fly fast and loose and often without regard for the heavy burden it puts on family, friends, and employees.  But as Churnless spins down, I’m certainly struck by people’s reactions to the news and (at a lovely meta level) my reactions to those reactions.

Almost everyone’s assumption (that we went out of business because we weren’t making money) is wrong: we were very, very profitable for our employees, our clients, and ourselves.  But it isn’t surprising that that is where people tend to go first: the dominant American viewpoint is that if a business closes, it must have “failed”.

But failure implies that we somehow lost the game.  Instead, we folded gracefully in favor of a better hand: our clients had plenty of advance notice, our team got time to find new jobs and personal introductions to good companies, and we were able to walk away with some cash.  And in doing so, we improved our board position in favor of new cards that I think both Avi and I feel will form a stronger hand.

And therein lies the first bit of the song: when to hold, when to fold.  Businesses are not simple win/lose propositions.  Like anything with an opportunity cost, you can be doing well but not as well as you would if you just laid it down and took the next deal.  So to be a good entrepreneur, you have to know which hands are worth standing by (even when doing so seems crazy) and which ones are worth shutting down.

That actually flows nicely into the next part: walking away versus running away.  A good call on when to fold allows for some grace in departure (which means bonuses for your team, time to find new positions, etc.).  A poor read of the board, on the other hand, means an ill-timed dash.

Which isn’t to say running away in a flat out dash isn’t sometimes the right way to exit a hand.  I’ve seen some pretty brutal spindowns where instead of just closing the doors and going home, people get let go one employee at a time as a company spirals straight into the ground.  Better an emergency landing than a crash.

And lastly, counting your money.  Entrepreneurs love money as as metric for success, which is ridiculous in that most entrepreneurs could make more money for far less work taking corporate jobs (a fact that doesn’t frustrate corporations nearly as much as it should).  Because money is the metric, that’s what they maximize for when they end a company, whether they are taking the hand or folding it down.

The trouble is, the game is more than just one hand; in fact, life is more than just one game.  And maximizing your life doesn’t mean maximizing every single hand (indeed, Barry Schwartz’s Max/Sat and Life Satisfaction work would suggest it means not maximizing most of them).  The best time to worry about money is when it matters: after you’ve spun down.  Only then do you need to start deciding on next steps for yourself personally; until the day that the company no longer exists, your responsibility is to your employees, clients, and partners.

By the Churnless calendar, as we spin down our last few things, soon will be time for countin’.  Until then: Muppets.