Sometimes, on the less important decisions, you might get out of it by default — A disagrees with B, but doesn’t care enough about the topic to actually do something about it, so B proceeds anyway.

Sometimes, decisions will be dictated by competence. If A disagrees with a proposed solution because of objective technical or legal implications, well, that’s it.

Quite often, though, there is no such solution. This is where one must be aware of the dangerous tendency of consensus-based teams to devolve into compromise-based discussions.

Consensus-based discussions feel like this :

A: I’m going to frobnicate the thingamajig.
B: If you frobnicate the foobar instead, you would get a 10% increase in floogum output.
A: You’re right. Let’s frobnicate the foobar, then.

That is, initially differing opinions evolve through an argumentation process, so that everyone agrees that the final outcome is the best one.

Compromise-based discussions feel like this :

A: I’m going to frobnicate the thingamajig.
B: I would rather that we frobnicate the bazquux instead. Might get better results.
A: Actually, I have a hunch that the thingamajig is the better option.
B: Tell you what, let’s frobnicate 50% of the thingamajig and 50% of the bazquux. This way we have everything covered.
A: All right.

Here, initially differing opinions are settled through a negotiation process, so that everyone’s input is respected, but no one agrees the final outcome is really the best.

Compromise is a bad idea for several reasons.

• Quite often, going 100% with any reasonable solution is better than investing only 50% into two different solutions. In more general terms, lack of commitment to a single strategy or objective is a dangerous thing to do, and often less effective than commiting to any strategy or objective one might come up with.
• Compromise is not agreement, it’s negotiation : you give something and get something else in return until everyone agrees that it’s an even trade. People who are good negotiators tend to dictate their terms in such circumstances, and others might feel helpless and useless after a few unbalanced trades. It also leads to « I agreed with your idea yesterday so agree with mine today » or « You’ve already changed my idea enough, stop asking me to change it again, » both of which are content-free sentences that aim to make a decision based on interpersonal history instead of objective analysis.
• The inability to come to a logical conclusion sometimes happens because there is not enough data available to decide. The first priority in such circumstances should be to actually search for the data (possibly accepting one of the proposed solutions as temporary until the data is collected), not settling for an arbitrary compromise.
• Building consensus is hard when people have trouble putting their insight into words, no matter how convincing or true that insight might be. I’m objectively right, but I cannot seem to explain to you the reason for it. This can mean going for a compromise today instead of a consensus tomorrow — hasty decisions are seldom good. Always make sure everyone has had enough time to think the decision through, even if it means adjourning it until later.

We negotiate several times a day, even if we do not recognize those occurences as such — « accept or walk away » is a fairly instinctive, if somewhat inefficient, negotiation strategy, and it goes hand in hand with the modern « take it or leave it » strategy employed by most mass consumer shops.

What is negotiation anyway, and why does it happen?

It happens because when humans cooperate, they get a cake that is bigger than the sum of its parts, and they need to decide how to split it. For instance, if I grow potatoes and you breed cattle, we could decide to put together my delicious Désirée tubers and your tasty Charolais steaks, which is a big improvement over otherwise potato- or beef-only diets. And then, we would argue over how much of the final mix each of us would get:

ME: We both contributed equally, so let’s get 50% each.
YOU: Breeding cattle is harder than watching potatoes grow, so I want 65%.
ME: Suit yourself, I know a guy who only asks for 55%.
YOU: Fine, I’ll go as low as 60% because I like your blog.
ME: I just told you I know a guy who…
YOU: …and that would save you the effort of finding that guy before lunch.
ME: Right. 60% it is, then.

You were a good negotiator, so you managed to squeeze 10% out of this. What happened? Let’s break this down.

Irrational Arguments

« We both contributed equally » might be true. Maybe I spent as much time growing my potatoes than you spent working in your ranch. But that is not my argument. What I have written between the lines is that it is fair for equal efforts to receive equal rewards.

And fairness is not a rational argument. It is a subtle way to circumvent rational thinking and aim for our unconscious ethical programming and, by definition, make decisions that are not in our best interest. In the eyes of a good negotiator, this is a loophole to be exploited.

There are many other such loopholes in the human mind. My favorites are:

Reciprocity is an atavistic impulse to give back whenever we receive something, even if that something is mostly unrelated to our objectives. In the example above, going from 65% to 60% is cleverly framed as a gift instead of a simple acceptance of my terms, which makes me unwilling to further haggle over whether it should be 57.5%.

Imprinting is our tendency, when we have no idea how much something is worth, to go with the first guess, clue or hint that we find about it. By suggesting a 50-50 trade, I imprinted you on the idea that potatoes are about as valuable than meat, and this serves as a basis for your « reasonable » 35-65 counter-proposal instead an extreme trade like, say, 3-97.

Guess what the market rate for potatoes and Charolais steak is? 3-97. I would like to correct my previous sentence:

You were a good bad negotiator, so you I managed to squeeze 10% 37% out of this.

And then, there’s a slew of emotional manipulation that does not appear at all in my example above. You can feign disappointment to try and get more out of a deal — “I really hoped you, of all people, could get this done for me.” You can pretend to be offended, shocked or angry in order to cause a large shift in the terms being negotiated — when you haggle in a bazaar, quote a price that is too low and you will be told that it is insulting, and kicked out of the store.

There are many other examples. Go read this blog article and read Predictably Irrational by Dan Ariely.

Rational arguments

You might expect this section to be as rich as the previous one, but it is not. There are only two different rational arguments you can say in a negotiation: “I will  not accept this outcome because [credible reason]” and “You will accept this outcome because [credible reason]“. Let’s examine our conversation with this convention:

ME: Suggests 50-50
YOU: No, because [breeding cattle is harder than watching potatoes grow], suggests 35-65
ME: No, because [I know a guy who only asks for 55%]
YOU: Suggests 40-60
ME: No, because [I know a guy who only asks for 55%]
YOU: Yes, because [that would save you the effort of finding that guy before lunch]
ME: Accepts 40-60

This is the reason why the most fundamental principle in negotiations is be willing to walk away. If you cannot or will not walk away, and the other guy knows this, then you can no longer say « No, because » and this cripples your ability to negotiate properly.

Typical reasons why I will not accept an outcome:

• The costs are greater than what I get out of it. Maybe I’ll ask for more money, or non-financial benefits (exclusive rights, free advertising…)
• It’s too risky for me. Maybe I’ll ask for insurance, or add terms to our contract that provide me with acceptable protection.
• I can get a better offer elsewhere. You can either match that offer, give me something I cannot get elsewhere, or give up.

Typical reasons why you should accept an outcome:

• There are additional benefits you did not take into consideration, such as not spending the time to find a better offer elsewhere, or my goodwill in terms of future trades, or my reputation as your client/provider.
• If you do not accept now but change your mind later, I will not be able the same offer to you again in the future.

These reasons do not have to be true, they only have to believable. I don’t know anyone who would accept a 45-55 split on potatoes and Charolais steak, but you don’t know that, so I can still bluff my way through our negotiation, bringing you down from 65% (which is still a 32% win for me) to 60%. If you knew that no sane person would accept a 45-55 split, you could certainly call my bluff and even bring me back up to 10-90 or so.

How you present those arguments is a matter of style. Here are four different ways of presenting the same argument (you will not get more than $30k for an APL job) :

1. No one else in town hires APL developers like yourself, so you either accept this $30k job or get out.
2. I am certainly interested in your APL skills, but I would be losing money if I paid you more than $30k.
3. We are looking to fill our APL development position, but I am not at liberty to offer you more than $30k.
4. We have interviewed several candidates with your skills, and most of them are below your wage requirements.

Some aggressive types would prefer approach 1, while manipulator types would go with 2 (which is a lie), passive types would hide behind a third party authority using 3, and sneaky types would try to get an even lower salary quote by withholding the $30k figure in approach 4.

Alternative Benefits

This is a subtle but essential part of many successful negotiations. It’s not only about the money. In the above example, I traded 5% for the ability to get my food in time for lunch — a concept that had not been mentioned at all before. You decided that instead of matching my requirements as I expressed them, you would offer me something that was unexpected and which, to you, cost less than 5% but still, to me, was worth at least 5%.

Going down alternate routes is an excellent way to get a stuck negotiation moving.

Article Image © William Neuheisel — Flickr

It all started with my frequent stays at my grandparents’ house, a conventional second-floor flat in Bucharest, where my grandmother and grandfather took turns babysitting me while my parents were out hammer-and-sickling (well, laboratory-and-architecturing) the socialist ideal. My grandfather was intent on turning me into a bright scientific mind, so he asked my uncle to build me a computer. Nothing fancy, mind you : it had no operating system worth mentioning, no hard drive, and depended on magnetic tapes and 8″ floppies to actually work. My grandfather showed me a standard BASIC interpreter, and had me type in a program that displayed, line by line, an analog wall clock.

Fascinated, I started spending my days on that thing writing BASIC code, learning how to build increasingly complex programs, and starting my career as a programmer. Or so had my grandfather hoped. A few seconds after discovering computer programming, I discovered computer games, which were a far more fascinating novelty than displaying wall clocks on a screen. I promptly forgot about the BASIC interpreter and for nine long years, I assumed that programming computers was some sort of esoteric arcane art, invisible to the uninitiated, and remained entirely uninterested in it.

Instead, my breakthrough as a rational mind was triggered by the close proximity of two unlikely catalysts : one was a frequent diet of mecha anime (the quality of the Romanian dubbing was hilarious), and the other was a cupboard drawer full of bits and pieces that could, to a child’s mind, be spare parts out of which a robot could be built : wheels, small electrical engines, cables, batteries, microprocessors, light bulbs… as a matter of fact, once I had the basic understanding of how a batteries + cables + engine setup worked, I did build small uninteresting contraptions.

I became intensely interested in building a robot myself. Obviously, I did not have the technical skills or the willpower to follow through with this plan, but I would listen, entranced, to any explanations I would receive that were related to robot-building. My grandfather was writing a book on semiconductors at the time, so he showed me a large digital circuit and let me understand that this is what the brain of a robot would look like — only quite larger !

And so he started teaching me the elementary principles of digital circuits. We spent little time discussing the underlying technical details, and instead concentrated on the simpler abstractions of logical gates. This time, I was fascinated. I would grab a pen and paper and draw circuits for fun. The meaning of AND, OR, NOT, NAND, NOR and XOR are imprinted in my brain ever since I was five years old… there are few concepts remaining in my brain that have been there for so long.

My circuits behaved like mathematical functions : I would mentally set the input bits, and the output bits would contain the result, so I could build the truth tables that mapped input combinations to output combinations. I experimented with basic arithmetic functions, learning binary as I went. And then one day my grandfather showed me a circuit that I could draw from memory to this day : the RS latch.

The fun thing about the RS latch is that it cannot have a truth table. It is an entirely different beast from arithmetic “write input bits, read output bits” circuits in that it has a state. If you write 1 to the S input bit, the output becomes 1 and remains 1 until you write 1 to the R bit, at which point the output becomes 0, and so on. To say things differently, the S input bit stands for “Set” and sets the output to 1, and the R input bit stands for “Reset” and sets the output to 0. When both R and S are set to 0, then the latch output bit is equal to whatever it was previously set to.

The RS latch is a versatile little thing. It can be used to implement RAM (one of the first things I did with it), or it can be chained to create an incrementing counter.

After a while, my interest in digital circuits faded, but the effects it had on my character were permanent : I now had experience applying abstract rules to abstract concepts, and it was fun.

Article image © Cornelia Kopp — Flickr

Many blogs about technical hiring will at one point state something about buzzwords and programmer flexibility. One of the original trendsetters, Joel Spolsky, said:

The recruiters-who-use-grep, by the way, are ridiculed here, and for good reason. I have never met anyone who can do Scheme, Haskell, and C pointers who can’t pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone.

And this is not only a point about elite languages like Scheme-Haskell-C versus mundane languages like Java-PHP-whatever : flexibility, the ability to switch languages and to adapt to new interfaces and libraries, is almost always presented as a prerequisite to being competent. John can perform miracles with PHP but cannot easily learn Ruby ? Then John is not a competent programmer, he is just a competent PHP programmer.

Maybe there is some truth to this characterization. Maybe there is indeed something about good programmers that lets them shine in a language-independent way, with languages as mere details of their day-to-day miracles. But I am vaguely uncomfortable with that notion. And not for personal reasons — my current language of choice is one of those elite functional languages that would hypothetically place me at the apex of the competence food chain.

I believe the critical element of programming competence is not ability but passion. What makes you a good programmer is how much you care about software development. Does John have a nine-to-five PHP programming job and hardly touch the computer outside of work, or does he do small projects on the side, or contribute to Open Source PHP software, or answer technical PHP questions on Stack Overflow, or perform any other number of PHP-related activities that do not have professional rewards as their main objective? Does he unconsciously try to do the right thing in his code, even though it will be harder than writing a dirty hack to make his boss happy?

I have seen people, many of them high-ranking academics, with the intellectual firepower to outgun me in any programming-related endeavor, but a striking lack of passion that let their applications crippled, hideous and unreliable. And I have no doubts that, had they cared about those things, they could have done better.

I have seen people, many of them students, with a genuine passion for software development, who would spend their free time hacking together video games or dynamic websites or clever hacks, who would notice after a while that their abilities were stagnating and, unable to improve, would give up programming rather than live with the frustration of writing software worthy of their expectations.

And when you care about programming, you tend to have strong opinions about how it should be done.

Some of these opinions are trivial. My hair stands on end whenever I have to read badly formatted code — I don’t care about the opening-brace-position flame wars, any convention is fine by me as long as it is consistently followed — and the authors often wonder why I would care about such a silly thing. I have a strong opinion about how code should look like, and I dislike working with people who do not share that opinion.

Yes, I am one of those Scheme-Haskell-C elite programmers, and I can pick up Java in a few days and outperform experienced Java-only programmers. I have done it several times in the past. And every single time I did so, I felt dirty and miserable, because Java goes against several of my opinions about what software development should be like.

In fact, I am not really surprised about the popular success of Python and Ruby on Rails — not in terms of how many projects are written, but in terms of how outspoken the technical advocates are. This is because those two have something that appeals to people who can become passionate about them : a clean core philosophy you can agree or disagree with.

Python zealots flock around the Zen of Python :

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Ruby on Rails fanboys have a similar set of core beliefs, the Rails Way:

DRY – “Don’t Repeat Yourself” – suggests that writing the same code over and over again is a bad thing.
Convention Over Configuration – means that Rails makes assumptions about what you want to do and how you’re going to d o it, rather than requiring you to specify every little thing through endless configuration files.
REST is the best pattern for web applications – organizing your application around resources and standard HTTP verbs is the fastest way to go.

So, if you happen to wholeheartedly agree with the Ruby on Rails way, then by using it you are certain to find both a technical environment in which you can feel happy, and a community that shares you strong opinions about software development. It is any wonder, then, that people passionate about the RoR values would flock to RoR and, inevitably, start advocating its use?

Going a little bit further, if you are hiring for your software company, would you rather hire someone with weak opinions on most topics because they are «flexible» or someone with strong opinions that match the strong opinions of your company? Given the choice, I would certainly hire the latter.

I have my own «core philosophy» that I apply to the way I write my own code. These would be, by order of decreasing importance:

1. It is better to have a correct program with few features, than a buggy program with many features.
   If possible, take the time to design your code and your interface so that errors cannot happen. If not, explicitly detect and display all errors as they happen. If possible, have a programming language and a programming style that can eliminate by design many errors, rather than a programming language or programming style that improves productivity at the cost of having more errors.
   
2. It is better to prove the correctness of a program, than to test for the existence of bugs.
   Tests cannot prove that the software is correct, they may only prove the existence of bugs. A proven program contains no bugs, there is no worry about having enough code coverage and enough test cases. This is a special case of “fail early” : better to fail at the compilation stage, than to fail during tests or at runtime.
3. It is better to accept that code will have to be rewritten, than to future-proof a complex design.
   Future-proof code will likely be larger, and contains more untested pieces, than normal code. This increases the probability of bugs, without completely eliminating the possibility of a completely unforeseen design change that still involves a rewrite. Preparing your code for a rewrite, by splitting it up into clean independent self-documenting modules and creating automated correctness checks for these, is the best way to make it flexible.
   
4. It is better to enforce data constraints through types, than to enforce it through code.
   Attempting to store data that violates the constraints fails earlier if the type cannot represent that data, especially in a statically typed language. Doing things this way might take longer than just keeping a flexible data type and performing the constraint checks in the code, but the odds of it being correct are higher.
   
5. It is better to have the computer do work for you, than for you to do that work yourself.
   Why write trivial unit tests when you can harness the type system to perform those checks? Why define or configure things by hand when your framework could define or configure them for you?
6. It is better to rewrite your code using new concepts, than to insist on using existing but ill-adapted concepts.
   Concepts improve productivity and readability, and by design will prevent some kinds of incorrect usage, but only as long as they match what the software is expected to be doing. Otherwise, at best they will be a useless weight and at worst will have to be tediously worked around to achieve anything. The size of the refactoring is no obstacle: if half the application needs to be adapted to the new concept, then so be it.
   
7. It is better to repeat yourself from time to time, than to introduce too many concepts.
   Any repetition can be eliminated by adding a new abstraction through refactoring. That abstraction is usually a mere application of an existing pattern or concept, but might sometimes give flesh to a new concept. While that concept arguably already existed in the non-refactored code, it is easier to understand uncommon concepts by looking at their repeated code, than to give them a sufficiently understandable name.

I don’t know. Maybe someone might agree with me one day.
Article image © Timo Newton-Syms — Flickr

I didn’t get past the signup form. Not because of any bugs or technical difficulties, but because of this:

So, it turns out that to connect to Jumo, you need to have a valid Facebook account. Why not? Letting your users connect through Facebook is a good strategy to gather information easily (it lets the user import his personal information from Facebook instead of typing it by hand). Requiring a Facebook account is probably a bit too extreme in my opinion, especially when it’s technically unnecessary, but I can live with it, especially since my Facebook profile is designed to contain only public information.

The showstopper here is that I need to grant permission to post on my wall. I’m utterly and irrevocably paranoid about my online image, so anything that looks like me saying things I don’t actually want to say is grounds for immediate rejection. I have absolutely no idea what Jumo is going to do with this permission once granted, and the last few times I’ve seen that permission granted by my friends, shady applications flooded their walls with advertising for other third party sites said friends knew nothing about. I’m pretty sure Jumo is not going to do that, but them asking for permission can only mean one thing: sooner or later, a message from Jumo will appear on my wall without letting me review its contents first.

Ultimately, this is a gamble: by asking for wall access, Jumo is willingly throwing away all the reputation-obsessed people who will not grant that permission, but earns the right to post a message on the walls of all those people who don’t care enough about Jumo to write that message of their own accord. And they’re playing their cards just right, because people like me are a minority. But that doesn’t mean it’s not a cheap, dirty trick.

A recent experiment by Ryan McKay illustrated this quite clearly. Subjects were grouped in pairs, one of the two was given a lump of money and told he could share any or all of it with the other. The second subject could then spend the money he received to reduce the first subject’s earnings at a 3:1 ratio (so spending $1 would reduce the first subject’s earnings by $3), thereby punishing him for being unfair. Priming the second subject with words related to religion caused the second subject to have a significantly more aggressive punishment behavior — they would rather lose $1 than have an unfair individual earn $3.

Combine this with Dan Ariely‘s conclusions in a cheating-based experiment: subjects were given a timed examination, and were rewarded based on how many questions they said they had answered — so you could cheat and say you answered all the questions, and get the maximum payout, even if you did pretty badly on the test. The first conclusion was that everyone cheated by a little amount, which is fairly interesting in itself, but the second conclusion was very surprising: by asking the participants to remember the Ten Commandments before taking the test, all cheating was eliminated, including those people who self-identified as atheists and therefore had no earning-points-for-the-afterlife motivation to respect the Ten Commandments. Ariely’s entire talk is pretty interesting for that matter:

In short, we’re nice to each other because 1° that’s the way we were conditioned to be and 2° the others will punish us if we don’t. The problem with the Internet is that it’s a mostly anonymous environment, so reason 2° goes out the window. You can’t punish someone you don’t know and probably lives in a different country. It follows that people who are not affected by reason 1° and find out reason 2° does not apply will take advantage of everyone else.

The New York Times ran a moving piece about Vitaly Borker, who has set up a fairly interesting business model: he waits for people to land on the web page of his DecorMyEyes online shopping site, and buy a pair of designer glasses. Once this happens, he buys fake glasses from eBay, ships an incomplete package and charges more than what was billed. From the New York Times piece:

[She] placed an order for both the Lafonts and a set of doctor-prescribed Ciba Vision contact lenses on that site, DecorMyEyes.com. The total cost was $361.97. [...] The next day, a man named Tony Russo called to say that DecorMyEyes had run out of the Ciba Visions. Pick another brand, he advised a little brusquely. [...] With the contacts issue unresolved, her eyeglasses arrived two days later. But the frames appeared to be counterfeits [...] Soon after, she discovered that DecorMyEyes had charged her $487 — or an extra $125.

And once the customers ask for a refund or threaten to get their money back from their bank, DecorMyEyes threatens them with lawsuits, and stalks them on Google Earth and sends them a picture of their home to bully them into giving up their money.

The elegant part of this business model is that this outrageous customer «service» means those people who ended up on the wrong side of a DecorMyEyes transaction will complain about it on the internet. The typical Google search for DecorMyEyes yields pages upon pages of angry «don’t buy from DecorMyEyes» customer reviews. This should even the odds and let everyone know it’s a hellish scamlike business, right? Wrong. Most people will never do a search for DecorMyEyes, even if they’re about to give them their credit card number. Silly humans. On the other hand, since all those angry reviews invariably linked to the company’s website, their Google rating blew through the roof, which in turn let them end up in delicious spots in searches that really matter, like «Ciba Vision» and incidentally prove me right as far as my earlier theories about scamming go:

• Relying on repeat business is impractical — glasses are a rare, costly expense.
• There are no dominant brands that own the market — at least, not on the Internet selling French glasses in the US.
• There is little to no contact between potential customers — because humans don’t do reputation research.

Customer losses are estimated at $1.7 billion. Nice one. Vitaly Borker has been going at it for at least two years, and there’s still no public righteous avenger wrath going on. The Internet is too busy righteous-avenger-wrathing a lady who puts a cat in a trash bin to go after a billion-dollar bully.

Silly Internet.

After a few weeks, there’s one lesson to be learned : in a start-up, there is no such thing as ASAP.

Suppose I’m your core product developer (not a very bold assumption) and you need me to fill in some administrative form, because you’re in charge of asking for a government grant. There’s a pretty tight deadline, so you tell me to send back that form ASAP. The problem being that almost every single other thing I need to do needs to be done ASAP: set up the production server backups, correct that bug that sends ten thousand password recovery e-mails for every single request, submit some critical information for a conference we’re attending, and give some developer from FoobarCorp technical details about our API. So, there’s a chance that by the end of the week, I’ll be done with your form, unless the server dies at 11 p.m. the day before and I spend the night bringing it back to life.

You know that the administrative form is a 10-minute task that needs to be done by Tuesday evening and that could win or lose us $25,000 but I don’t have any information about it other than its urgency. Why is it so important? I know why the server backups are important because I’ve put them on my todo-list myself and I have an intimate knowledge of what is at stake. I know what it means to receive ten thousand e-mails for a single password request. I just cannot feel the same about an administrative form that you dump on me. In fact, the only reason you said it was to be done ASAP might be that for the last few weeks I’ve been passively filtering out any non-ASAP requests from you. The oral equivalent of writing V!agra instead of Viagra to get your spam e-mail past the spam filters.

It’s nothing personal. It’s just a consequence of three environmental factors:

• Everyone is overworked, so tasks that are not blatantly important might be postponed forever.
• We’re equals, so you can’t give me «drop everything and do this now» orders.
• You didn’t give me enough information to decide how important your request is.

This is a nasty mix. To get over it, there are two simple rules you can follow.

The first rule is the requester’s responsibility: always add a deadline to your requests. If you tell me that you need those forms for Tuesday evening, there will be no ambiguity as to the urgency of the matter — I could have questions about the priority (is this form more important than setting up the server backups?) and it’s up to you to defend the importance (this could win us $25,000) until we agree on whether the action is must-have ($25,000? of course we’ll do it), nice-to-have ($250? I’ll see if I have time…) or ridiculous ($2.5? are you kidding me?). Basically, we’re working together to help me fit this new task in my own mental priority queue.

The second rule is symmetrical: always ask for a deadline. «We need to frobnicate the product as soon as possible» could equally mean «drop everything and frobnicate the product immediately or we’ll be sued to hell and back» or «make a mental note to add frobnication on the Q3 2011 wishlist» and whatever level of urgency you thought you heard is probably not the level the requester intended. You can ask for a deadline explicitly, or you can provide a plausible deadline based on your current load — do whichever you believe fits the situation, both are ultimately equivalent.

Many successful people around me (and by successful, I mean the target of my secret envious hatred) have a strange and yet obvious personality trait: they believe the things a person does are an accurate reflection of that person’s quality as a human being. For instance, they might be convinced that a person who wakes up at 9:00 am on a Tuesday is a lazy sloth that is subtly inferior to non-lazy non-sloth types. What reflections a given action casts is ultimately a consequence of their upbringing, education and personal beliefs — in two men kissing each other in public, one may see perversion and shameful sin where the other sees courage and happiness. You will never hear these people utter «well, he can live his life however he wants» about anyone — in anything, they see either grandeur or mediocrity, but never open-minded neutrality, and anything that may sound like neutrality is either polite self-censorship or bored indifference.

These people are sincere. Not only do they say that waking up at 9:00 on a workday is irresponsible, but they wouldn’t be caught dead waking up at 9:00 on a workday. The noble, respectable thing to do is to wake up at 7:00 and they will do so because their pride and their opinion of themselves depends on it.

And that is why they’re successful. Let me explain.

Everyone wants to be successful, because everyone hates mediocrity. And yet, if I asked you «What’s your plan for being successful?» it would involve a lot of hesitation and a lot of things that are oddly reminiscent of things you are already doing (ironically, that’s also what the successful people would answer, but at least they’re right). The biggest issue with being successful is the lack of a road map.

The end result is a descent into mediocrity: when you were a small child, you wanted to be an astronaut. When you were in middle school, you had lesser yet prestigious dreams of having a great job and living in a great neighborhood with a great family. As you get older, your job and home expectations get increasingly lower as you find outsome of your objectives are too difficult to achieve, until you decide you’re lucky to have whatever you ended up with.

Those people who have a sharp opinion about every single thing around them? They have a much easier time avoiding that slippery slope, because «I guess this is acceptable» grey areas are simply not a part of their world view. If they took a second-rate job anywhere, it would sting like sharp, rusty jalapeño-coated needles. They have a ten mile wide road map with «you are not here» written all over it in blood and tears of shameful disappointment. No wonder they ended up where they did. And they cannot find any excuses, because they’re not just trying to impress their friend or keep up with the Joneses: the only judge of their eventual success is their own opinion of what is great and what is not.

Are you happy with yourself? With your job? With your home? They never are.

It sounds like a sad life. But I ask: is a parent not constantly disappointed with specific things their child does, and still proud of him at the same time? The way to stay sane is to constantly remember that things should be better, and yet to be proud of the life you lead.

• Share the cost: What I use costs the company money. They went to great lengths to drive the base price down, so it’s only fair that I participate in any additional expenses I cause.
• Avoid free riders: If I don’t have heavy luggage or use the restrooms, I won’t have to pay for the kerosene spent carrying around other people’s luggage or the water for their restroom usage.

That’s why a Low-Cost model cannot charge for wearing a blonde wig : the wig doesn’t cost the airplane company anything, so there’s no reason they should charge you for it.

This obsession with fairness goes head-to-head against traditional economic theory. In a traditional economic world with purely rational agents, everyone agrees that a printer that prints 100 pages/minute costs more than a printer that prints 20 pages/minute. In our real world, if the 20-pages printer is the exact same hardware as the 100-pages printer with a speed inhibitor tacked on, bloody murder will be screamed. Of course, big businesses don’t care — it’s a game everyone plays, so they’re going to negotiate discounts and settle for the higher price anyway — but if you’re targeting the B2C/B2IB market and they find out you’re into that kind of backstabbing, you’re done for.

If you’re going for a product with multiple prices, or with additional features available for a fee, remember that customers will be looking at the price difference through two very different lenses:

• Is it worth it? Does that $5 feature provide me with happiness or productivity that exceeds $5?
• Is it fair? Does that $5 feature cost the provider anything close to $5, or are they just gouging me for the fun (and gross margin) of it?

In the software world, we’re all concentrating on the first question, but we had better keep away from the second one : writing software is dirt open-source cheap.

It’s fair to ask for some money when you’ve spent weeks working on a feature. It stops being fair when you cripple your software to create a cheaper version. And by «cripple» I do not necessarily mean removing or blocking existing features: willingly straying from the optimal design to be able to monetize a feature that would have been an immediate consequence of that optimal design.

Are you providing some of your users with daily backups, instead of guaranteeing that you will never lose their data?

Are you trying to sell data recovery features by selling a product without a revision history tool?

Are you actively fighting third party data conversion tools to force customers into buying your own data extraction plug-in?

Are you limiting the number of anything (users, posts, files…) that the users are doing with your software on their computers?

What do you enjoy about this project? What do you utterly hate about it? What’s the long-term motivation that keeps you working on it : fame, money, passion, something else?

What are the day-to-day activities that you love doing? What would you rather not do? Do these match your actual skills, or are you unskilled in what you love and hate what you’re skilled in?

When and where are you the most productive? Are you a regular worker, or do you have infrequent bursts of productivity?

I’m glad you took the time to know all of these tidbits about yourself. It really helps.

Have you told the people you work with? Have they told you what makes them tick? If not, how do you know you’re working with them and not against them?