Only now I’m realizing that even phrasing a question this way is already a mistake. If you’re this far down your path and you have no proof that your idea is right, chances are, you’re up for a big, unpleasant surprise.

My favorite radio show, “This American Life,” had an episode a few weeks ago  with a story of a guy running his family’s well-being into the ground over 3 years, all while trying to launch his own TV show. He had essentially zero traction. He kept getting himself further down the hole since the day he started.

Rand Fishkin, a wise and successful man, gave an outstanding speech about making mistakes at a conference this year. He showed a graph of his net worth – falling through the floor for several years in a row. He kept doing the same thing with the same sad result. And only when he realized his mistake, his career turned around.

It’s curious how our culture romanticizes perseverance, sticking with the ideas once things go sour, and pushing through all the obstacles. There’s certainly a healthy dose of stubbornness that is necessary for an entrepreneur to succeed. But all too often, I see this idea taken all too far – instead of healthy tenacity, the belief of the founder turns into arrogance, and no fact in the world can change their mind.

Einstein said this best: the definition of insanity is doing the same thing over and over again and expecting a different result.

Stop sticking to stupid ideas, dammit. At the very least, accept the fact that you can possibly be wrong. And search for proof – quantifiable, objective proof – that the assumptions your idea is based upon are indeed correct. Eric Ries makes a powerful pitch for this concept in his book Lean Startup: formalize the foundational assumptions of your business; then, systematically test them – as quickly as possible.

In other words, if you have a smart idea, don’t bet your entire farm on it. Hedge your bets. Accept the fact that you can be wrong. Bet a little bit of time/money on your idea; prove out its most salient points before you mortgage your house and quit your day job. Why? Because too many ventures result in

 ”achieving failure”: perfectly executing a flawed plan.

You might argue that true visionaries like Steve Jobs or Bill Gates kept pushing even when nobody believed in their ideas. I will challenge you to fact-check: Steve Jobs had an order for 50 Apple I computers when the company was in his parents’ garage; Bill Gates famously sold IBM something that he didn’t have when he was 25 years old.

What are some of the ways to validate the assumptions in your technology startup?

1) Use non-code methods. Find a way to replicate the core of your idea – even at 50% efficiency – using a human being. Make it a point to write ZERO lines of code. You’ll be surprised to see that you have a great amount of data just a day or two later.

2) Use statistics! Just because option A did better than option B in your survey doesn’t mean that your customers prefer that option. Learn about statistical significance (you’ll be surprised how non-trivial these concepts are!) and run real A/B tests in both human-process and technology experiments.

3) Walk a fine line between “explore” and “exploit”: in optimization theory, there’s a well-known issue of a local minimum: if you exploit what you know about your problem space too much, without a healthy dose of open exploration, you’ll likely end up with a sub-optimal result. Keep your eyes open for possibilities in the nearby spaces; openly experiment in areas where you aren’t strong. Continuously invest time into exploration.

Use these methods to continuously validate your own ideas – no matter how great they seem at the outset – and never find yourself wondering 6 months into the effort: “am I even on the right road?”

It’s so difficult to tell when an incremental, continuous process turns the corner and radically changes its character, and a temptation – a very pragmatic temptation – is to allow for wiggle room and ignore the little deviations. Meh, just another check. Our company’s big and strong, and our success depends on macro efforts – who cares about a thousand dollar check for paper clips?.. Let’s concentrate on something bigger!

I’m typically not a fan of idealistic, black-and-white / cut-and-dry judgment philosophies. I try to look for the trade-off curve – if we give up a little bit here, can we win a lot there? I usually find that an obvious decision is typically not so obvious, that for each radical judgment, there’s a set of counter-arguments that deserve to be explored.

Yet, today, I found an area where a hard-line view – a view that doesn’t allow for a gray area – is extremely important. That area is about managing accountability. I had an amazing conversation with my CEO, Ben Elowitz, and he crafted a very convincing argument – I know that it’s one of those that will be pretty transformative to my leadership style. Here it is.

There are two ways to run an organization.

One is the way of the pragmatic.

Have flexible standards – we ship when software is ready; we are OK slipping a little bit. We value commitment, but we value flexibility as well. We are reasonable – we don’t create a panic around a missed expectation unless it really cost the business.

The other is the way of commitment.

Draw a hard line: EVERY commitment that we make, we keep. Our organization does not tolerate a single hour worth of slippage. Create symbols of accountability: generate gigantic, loud, visible stinks every time a tiny expectation is not set. Don’t do it to be an asshole – do it to prevent the tiny little bit of a creep.

Oh, it’s OK to be a day late. It’s just a day…

And then we’re three days late…

How is five days late bad? It’s almost the same as how we did last time (four days late), and you, our fearless leader, seemed to be perfectly happy with the results?..

And then when you have a deadline that your team must meet, how can you expect them to deliver – with this kind of culture?

Ben argues that there are three elements to high accountability, which he equates with high performance:

1. High standards: we set difficult goals, and hit them every single time. I don’t care that it’s 5pm on a Friday. You said that it’ll be done by the end of the week. Get to work. 
2. Symbols of these high standards: as leaders, we celebrate victories and are VERY, very upset when any commitment is missed.
3. Reinforcement – rewards and punishment – is immediately tied to the performance management / review process.

Even worse, if you commit to get something done by “the next meeting of this group,” you’re about to experience  Parkinson’s Law - people tend to do stuff at the very last moment before it’s due – it’s only natural and efficient:

Work expands so as to fill the time available for its completion.

If instead, you commit to getting it done by Tuesday 1pm – refusing to be bound by the timeline of meetings, instead giving a precise estimate in terms of hours of work – you’re in a much better shape from the get go. Tasks end up taking less time – all because you’ve framed the timeline differently.

Next time you’re thinking about whether to estimate dev work in days or hours, think about this.

Almost seven years ago, I walked into the largest software company in the world knowing basically nothing about software development. You taught me everything I know today. You taught me about ambition; about relationships; about due diligence; about customers. It’s been such a great privilege to learn from you. Thanks for this amazing experience.

I look back and think of the infinite patience of my managers – and feel so, so grateful. I vividly remember the day when Josh Bell, my first manager, told me that we don’t fix some of the bugs that we find in our products – knowingly! What?!? No Santa Claus?… I recall the heart-to-heart chats with my colleagues, where we found truth and challenged each other to be better. I can’t help but feel nostalgic. Thank you again. My brain got bigger, which obviously caused most of my hair to fall out in the process, but isn’t that what growth is all about?

Today, my path leads to me a startup – just across the water in downtown Seattle. I’ve taken a role of director of PM at wetpaint.com, a startup that aims to revolutionize media. My last day at Microsoft is July 14^th.

My field, software engineering, is young and filled with changing winds. Client-server! No, web-based!.. Win32! No, PHP! No, Cocoa! No, HTML5 / JavaScript!.. Mainframe! No, rich client! No, thin client! No, mobile client!..

Entire industry moves like the trees under a powerful wind. I’ll stipulate that there are two factors in play here:

1. Psychology. The nerds that are in IT leadership positions are still very much gadget nerds. They love new stuff. They love playing with new stuff. They get the fanciest gadgets available on the market today. It’s not the Patek Phillippe crowd – they won’t go after a 100-year-old watch. They’ll go after a released-1-day-ago iPad v7, stand in line for it for hours, and pay through their nose. Just because it’s new – and new stuff is really exciting.
2. Incentives of market movers. Large technology vendors – particularly those in the leadership positions in their markets – want to keep customers in the spot where they want to buy again and again. Yes, we sold you a solution to your problems yesterday; but wait, now we have a NEW, MUCH BETTER way to solve that same problem! Yeah, you haven’t yet figured out half of the benefits of the old thing, but the new thing – it’s SO MUCH BETTER!..

Abstractions are an outstanding concept in science: instead of dealing with a bunch of low-level concepts, we create building blocks – and juggle those instead. It’s much easier to build a house if you have bricks; it’s much easier to perform a surgery if you don’t have to make a scalpel from the iron ore yourself.

Perfect abstractions require zero knowledge of how the building block was created. Such abstractions don’t exist – even the surgeon needs to know a little bit about the manufacturing process and chemical composition of the scalpel. For example, the scalpel has certain melting temperature and certain chemical characteristics (hmmm, I guess I shouldn’t put it into hydrocloric acid..).

In software, most abstractions are actually pretty bad. We like to think that the operating system hides away most of the complexities from the users – but it doesn’t. With Android, unless you know to kill apps that are running in the background, your battery life will be abysmal. Even with the famed iPad, you have strange artifacts like “zoomed mode” for old iPhone apps – total weirdness from the end-user point of view.

ORM (object-relational mapping), one of the most famous abstractions, is probably one of the worst (most leaky) – it will make you *think* that you don’t need to know SQL, but my god, that’s a horrible lie.

And yet, for system designers, these abstractions are frequently natural. As software engineers that build those abstractions, we are tempted to design for ourselves. In the end, we’re developers that build on top of those frameworks, too! “How am I not the target customer?..” That, of course, is a horrible mistake that causes unusable abstractions and frameworks that only their creators can understand.

Enter cloud computing. The latest excitement of our industry. The premise is really simple – instead of investing into technology upfront, pay as you go. Have someone else host that technology for you. That someone has vast economies of scale. Increase your investment easily in response to demand.

Sounds like a dream come true to the enterprise, right? I have 50 servers that are each utilized at 3%; I have IT staff of 10 to maintain these technology solutions; that’s really expensive. Instead, I come to a cloud vendor and pay a fraction of the cost.

Also sounds like a dream come true to an independent software shop, right? With my Find Touch project, I used to need a server in my garage – maintaining hardware, network connectivity, software stack, everything. Instead, the cloud promises to solve all of the same issues at a fraction of the cost.

With cloud computing, the situation is even worse. The field is in the “new and super hot” realm – just like those pesky iPads – and early adopters are discovering that the promise of “just move your existing application into the cloud” isn’t quite working.

The lower the level of the service that you’re moving to the cloud, the easier it is to map to what’s in your datacenter. The higher you go up the value chain, the harder the migration becomes.

If all you’re getting from your cloud vendor is hardware, everything is pretty easy from the technology standpoint. The problem, of course, is that the value add of such a service is pretty low. Yeah, I can spin up more machines and I don’t need to wait for DELL to bring those machines to my doorstep.

If, on the other hand, you want to move a VB6 application into the cloud.. And gain the benefits of deployment, scalability, billing, and all the other goodness of SaaS.. Good luck. You’re in for a treat. Get ready to essentially rewrite your software. Oh, you no longer are in touch with the vendor that wrote the source code?.. Too bad…

Moreover, the further you go from technology towards business aspects of cloud computing, the harder the cloud becomes to understand.

Recently, I worked on moving my web-based application from a standard hoster (1&1) to a cloud platform. I chose Amazon EC2 for my experiment. MY GOD, even as a technologist, I was at loss to understand what the costs for my migration are going to be. My old platform offered a pretty large VPS; they screwed up with customer service, so I was looking for a new home. All I wanted was an apples to apples comparison of price and major features. I didn’t expect major demand spikes – even though the ability to respond to them is nice. All I saw was myriads of instance types and datacenter options and pre-pay versus pay-as-you-go per minute of usage and my head was spinning after an hour.

My god, can’t you just tell me how much I’ll pay for the load I *know* I will have? A stupid little calculator for idiots like me that will tell me how much I’ll pay a month?.. To see if your service is worth it?..

Hosting vendors have this down to an art: show just three options, with a clear feature matrix; highlight the middle one with a tad more features than most people want; help upsell that one.

Cloud vendors? We have EC2 and S3 and fancy queues and monitoring with a cool name and you need to learn all of those proprietary acronyms and oh my god am I going to have to have my IT staff relearn everything?.. Cuz my CEO sure isn’t going to like this..

Seriously?.. You call that an easy switch to the cloud?..

I’m not saying the cloud is a fad. I am, though, saying that the cloud is in a state where it’s “hot and sexy because it’s new” and it’s primarily driven by technologists – not the business leaders. I want to see cloud vendors lead with value proposition – and better abstractions – and not with the newfangled technology “fire and motion.”

I want to see someone who’ll take my PHP app and will put it into the cloud – for the same price for a single VPS as my dumb old hoster. Using the paradigms I’m used to. I want my app to *not change at all* in order to adapt a cloud-based billing service. I want my storage to work just like I’m used to. I don’t want my IT staff to learn anything new – I want the framework to adapt to THEM.

Let’s greet the cloud – and hope that it grows up from the infancy it is in now.

You’ll solve the immediate issue at hand. Of course you will – I have no doubt. Every hot tactical issue gets solved. Look back upon your past year – you’ll remember all those late nights, and you’ll see that it all worked out in the end.

Now look back 5 or 10 years ago. And try to remember the firefighting you did then.

What, having a hard time?.. The tactical stuff doesn’t float up in memory easily? What does come up?..

The people. The feelings. The relationships.

Oh.

Hmmm, interesting. I wonder what that means.

Fine, fine, I am a demeaning bastard. Give me a break, I just scored a free cocktail from a flight attendant.

What it means is that the only thing that matters in the long run is the people. You’ll forget the tactical firefighting. You’ll forget the problems you were working on. You’ll forget the problems, the technology, the contract terms, the programming language, the price you quoted, the vendor you hired…

The only thing you’ll remember are what you felt, who was by your side, who fell apart, and who really made sure everyone made it through.

You’ll keep that memory with you for the rest of your life – and so will the others that were next to you. When you are in need, the people that will help you will be those that have fond memories of you – it’s just as simple as that.

The only thing that matters is people. Invest in people around you. Make sure you comfort them in need. Motivate them when the tough times come and they need to work around the clock.

In the long run, it doesn’t matter how brilliant you are. If you’re an ass, you’ll end up nowhere (in our field, a particular section of nowhere is reserved for the arrogant asses). If you invest into people around you, they will cover for your misjudgements; they will forgive your stupidity; they will pay you back a hundredfold.

Go ahead and smile to the person next to you. Make them feel appreciated. Invest in them, make them better off. You’ll make a world a better place today – and you’ll be so much better off yourself tomorrow.

 ”Be nice to people on your way up, because you’ll meet them again on your way down.”

Joel Spolsky says it best:

I’m always on the lookout for these incentive schemes gone wrong. There’s a great book on the subject by Harvard Business School professor Robert Austin – Measuring and Managing Performance in Organizations. The book’s central thesis is fairly simple: When you try to measure people’s performance, you have to take into account how they are going to react. Inevitably, people will figure out how to get the number you want at the expense of what you are not measuring, including things you can’t measure, such as morale and customer goodwill.

This has far-reaching implications into motivating employees that are far from commission-based. Let’s take two simple premises that many large companies follow:

1. Reward employees on a curve (ex. 20% great, 60% average, 20% under-performing). Force that curve at every level of the organization to make sure that no manager can claim that his team is “all stars” and thus pull the blanket of rewards to her group.
2. Tie financial rewards for an employee are to their individual success only – that is, their relative performance compared to their peers, as viewed by a panel of superiors. The logic goes, if you tie employee rewards to product success, you won’t have stars joining struggling teams as they don’t want to be weighed down by failure.

Let’s think about what you get in the end from this explosive combination from a purely logical, reasonable employee. They observe that their own upside is completely disconnected from the success of their product. As a result, two kinds of behaviors start:

1. Backstabbing and political play. This one is kind of obvious and everyone talks about it: if I’m rewarded based upon subjective opinions of my superiors, I better kiss up to the superiors and make my peers look bad.
2. Poor hiring. Who are the people doing the interviewing for new talent in your organization? The same people that you apply the incentives to. “If I hire mediocre people onto my team,” the thinking goes, “I will be a shining star at the next performance review!” Therefore, I’ll give a Hire to an intentionally bad candidate! This will ensure my continuous success in the organization, while decreasing the chances of the group as a whole to succeed.

OK, you’re in shock. You’re about to say that:

• I have to work with these mediocre people that I just brought into my group. Yeah, so what? I can hire really nice and really unproductive co-workers. I’ve seen plenty in my career.
• If everyone does it, the company will go under and there won’t be any cash wins for anyone! Yeah, except that when I see others doing it, I don’t want to be the one left out.
• This is plain immoral and intentionally malicious to the organization! Nobody would do this!

Do not ever place people in a situation where rational, logical behavior conflicts with their morals. Your counterpart will either suffer moral trauma (my wife really wanted to go to Hawaii, and there I am, not doing all it takes…) or do the thing that’s wrong for the business.

Here’s an intuitive way to approach this: if your friend lent you a MILLION dollars in cash tomorrow, with no contract or witnesses, with no trace of the transaction, would you be tempted to cheat them and pretend they never gave you the money? How about a BILLION dollars? An amount that will be enough to take care of EVERYONE you love and their grand-children, for the rest of their lives?..

Stop lying to yourself. There is a price for everything. People are rational beings, and they place value on things that are difficult to measure. You probably wouldn’t screw a friend for a thousand dollars, right? But for a BILLION? You would. Everyone would. Don’t put your friends in a position where their morals conflict with what’s good for them in terms of utility. And don’t ever do this to business associates, because I guarantee you – their loyalty to your business is lower than your loyalty to your friends.

Good fences make good neighbors. Good contracts make for fabulous partnerships.

Let’s imagine the following setup: a 10-engineer technology startup. A single product manager, responsible for the roadmap (what will our agile shop produce – and in what order). They also have commitments to the CEO and the board of directors around business timelines – for example, external partnerships lighting up by certain dates. The PM is also a Scrum Master.

Let’s look at an issue: an engineer frequently forgets to report the remaining/completed hours for their work items. There are several possible interpretations of the issue, and thus, several possible solutions. Let’s look at each of them in detail.

Scenario 1: I “just forget”

The engineer is, presumably, simply forgetful. Someone needs to remind them – and that someone is the PM, as they’re the scrum master. The PM essentially then becomes a walking-talking alarm clock – “Did you update your hours?” – “How about you, did you update your hours?..” Why are you paying a HUNDRED GRAND PLUS to a babysitter?

Allow me to doubt the feasibility of this root cause. Does the engineer forget to put their pants on? Usually not. Do they forget to run unit tests before the checkin? No. When was the last time they forgot to check in a file and broke the build? Never really happened. Hmm. I guess they aren’t a very forgetful person, in general…

Scenario 2: I don’t see the value

The engineer simply doesn’t see the value of reporting their hours. They see it as process for the sake of process. The annoying PM keeps printing the stupid report, and there wasn’t a single time when anything useful came out of following this dance yet.

Possible solutions:

1) Your organization might not need daily stand-ups and up-to-the-day updates on remaining work.

WHAT? DID YOU JUST SAY THAT WE DON’T NEED SCRUM? I’m closing this page right now and unsubscribing from your stupid blog!

Yes, I did say that. Scrum is not a silver bullet. Following the book to the dot will get you nowhere. If your next release is 2-years out, if there are no ambiguity in what you’re building, if you don’t have any budgetary/business/technology interruptions (this does happen!), you can go with a good old waterfall. Or you can change scrum to reduce the amount of daily overhead.

2) Your developer doesn’t have the knowledge that will help them understand the value.

Who uses the roll-up reports? Just the management team, to make prioritization decisions? And you’re wondering why the individual contributor dev has no idea why they should keep updating it? Because they see no value for THEMSELVES. Help connect the dots for them: what you do every day helps us make better business decisions this way and that way, which in turn moves the odds of our business succeeding – and you cashing in on your stock options.

Scenario 3: I don’t give a damn

You’re convinced that the engineer truly understands the value? You talked to them a couple times about it? They still don’t do it?

There’s only one explanation left. They are a lazy ass and don’t give a damn. They simply aren’t hungry – they are coasting along without really caring for success. Get rid of them. They aren’t pulling their weight and are negatively contributing to the morale of others.

…

In parting, I’d like to once again state – your engineers don’t need babysitting. They need motivation. Treat them like adults, like your partners – and they will pay you back with frenzied dedication and an amazing product.

Our field is full of socially awkward, yet really smart people, and many of them see such drastic intellectual superiority over many of their peers that they catch a fatal disease. At some point in high school, they got an A when everyone failed a test. Or, in their big company, they single-handedly saved the day and saved an entire department from slipping. Or they were a young prodigy in academia and wrote a famous paper.

This is when it hit them – dude, I’m really bright. Moreover, I’m so successful that it must be because I’m so much smarter than folks around me. In everything I do, I can only trust my own judgment – because it’s better than that of others.

And this is when they’re dead. Rand Fishkin, the founder of SEOMoz, calls this “the dangerous hubris of the startup world… the original and most serious of the seven deadly sins.”

They’ll be the ones to build a beautiful new gaming system, only to ship it with a controller that’s too large for half of the world to use. Or they’ll build a gorgeous car, and in their wisdom call it something that sounds great to their own ear – but means “it doesn’t go” in Spanish. All of these are the problems of leaders that think that they have the world in the palm of their hand – and they need no one else’s advice.

I stipulate that the cause of death of countless startups is the stubborn certainty of their founders to keep the original course. The reality is, most successful companies changed course drastically since their inception. You have to be flexible to admit a mistake, make a course correction before it’s too late, and vigorously attack the new path.

I’m a big believer that growth happens through what Einstein called a “school of hard knocks.” Through failure and humility, we see our own imperfection, and strive to improve on it. If we think we’re already perfect, the learning stops. The issue is that the others keep learning – and the world keeps evolving. If we keep using the same hammers for the new tasks, we’ll go extinct.

This issue is exacerbated by our talents. There’s a lot of really brilliant arrogant technologists out there. There ingenuity places them into leadership positions – thus putting not just them, but their followers in jeopardy.

Ask yourself, and be really honest – what were some of the mistakes I made in my professional life? What were some of my judgments that ended up being really false? I’ll point to Eric Sink’s Make More Mistakes article as a fantastic inspiration. The guy pours his soul out for the others to learn – it sure is a painful process, but my god, you get to internalize the lesson from those mistakes so well when you put them on paper.

Here’s a couple of my own dumb mistakes.

1. Do the market research before jumping head-first into a venture.

Cocktail Builder, my first entrepreneurial project. Premise is simple: put in the ingredients you have in your bar, it tells you what drinks you can make. Moreover, it says what stuff you can almost make – so that if you were to buy this one extra ingredient, you’d be able to make this cocktail.

Hey, I thought, when building this – I can sell the missing ingredients online, right on the spot! People are really likely to buy at this point! And so I go on and build the entire site. I market it, get pretty good traffic.. And then I start working on adding the monetization capabilities for selling liquor.

And that’s when I realize: you can’t really sell hard liquor online in the US. Ooooops. There goes that idea… and 8+ months of work with it.

2. There will always be people smarter than me. Find them.

Find Touch, my next entrepreneurial venture. My co-founder and I were convinced that we needed to amass a large client base by luring them with a free product offering, before we can follow on with a jobs marketplace that will leverage that client base.

Our first advisor and lawyer – thank you, David Marks – asked a seemingly obvious question: why aren’t you guys going for the real deal right away? Why not create a jobs marketplace immediately, instead of a silly entry offering that’s impossible to monetize? This question saved us months of work and ultimately made us a viable business.

Our second advisor – thank you, John Kueber – kicked us in the butt when we were obsessed with raising money. We spent 6 months agonizing over decks, financial models, introductions to angels.. All while we had basically no product and little traction on the marketplace. John made us drop this nonsense in favor of making the product sing – and in favor of getting some real customers use this product.

This is just the beginning of my list.. At this point, I know that I probably have more wrong hunches than right ones. That said, I do know one thing for sure – if you listen carefully, someone will quietly whisper a thought that never visited your head. You may just find a missing piece of the puzzle, if only you are willing to listen.

….

In parting, allow me to offer you a story from a friend. He was recently interviewing in a successful technology company for a senior position; he was speaking directly with a division’s vice president. He asked the VP a simple question: do you see the role of your employees as implementors of your vision, as an extension of your own capabilities?

The VP answered “yes, I simply cannot implement all of my vision myself, so I need my team to follow through on it. I frequently have issues where the team doesn’t quite understand the full scope of my intent, so they have trouble implementing it.”

Is it just me, or does that phrase smell like “I’m the smartest ass in town and I know the solution to every problem. I need cogs for my machine to execute my vision.” No matter how brilliant that guy’s vision is, his team is going nowhere. Innovation comes from diversity and from nay-sayers – from passionate, open, and respectful disagreements. Innovation comes from employees that have autonomy, mastery, and purpose as their motivators.

The interview goes on and on, and with every new topic, you find more and more reasons around why your initial sense is true. Hey, he didn’t give any credit to his peers. He invented it all himself, ha. What an ass!

This is all nice and great, except that you’re really sucking as an interviewer at this point. You had a gut feeling – you made a decision in the first few moments since you met the person – and you’re essentially looking for proof for your already made-up mind.

Since hiring superstars is your #1 priority, this mistake, in my book, is in the category of “lethal” if you’re a founder of a company and you’re bringing in employees #3, 4, and 5.

I’ll go further and stipulate that we’re hard-wired to be making such mistakes. There’s a curious amount of research on first impressions – the amount of judgment people pass on from the first 5 seconds of their interaction. In one leadership training class I took, they brought together a diverse group of people – completely different ages, industries, seniority levels. They had us pair up with a random person in the class, without exchanging a single word with the partner. Then, each of us gave some thoughts about the role, seniority, and industry of the other.

It’s shocking how precise – and how correct! – most of the observations were. The other person didn’t even open their mouth!..

The reason we’re hard-wired to make such a fast, snap call, I believe, is because of the basic fight-or-flight response. You need to judge whether the oncoming object is a danger to us; if we’re bad at it, we’ll get eaten. Thus, natural selection helps advance those that are good at it.

The problem, of course, is that at the workplace, the interactions are much more complex. You WANT to hire people that are radically different from you. You want to hire nay-sayers. You want people with radically different backgrounds, those that approach problems from the other angle. You want the whole of your company to be more than the sum of the individuals. If you fail to challenge your snap judgement, you’ll have a bunch of copies of yourself – creating an environment that magnifies your weaknesses, instead of compensating for them. Like the kings of the medieval times, you’re risking to suffer organizational hemophilia – the disease of “too much blue blood.”

Instead, I invite you to state the assumption that’s popping up in your head, and ask: what could this person say to convince me that they’re NOT what I think they are? If I think they’re not technical enough, can I ask them to code something? If I think they’re too full of themselves, can I ask them about a time when they were wrong? Literally, drop the current conversation topic, and abruptly switch to this new question.

Note that your first impressions, in some cases, will turn out to be exactly true. For example, one gentleman I recently met, I was getting a sense that he’s quite stubborn. I asked him to recall a time when he was convinced by someone else. A time when they thought one way was good and true, but someone jumped in and convinced them of a different approach.

The gentleman thought for a while, and came up with quite a telling example – as a business leader, he saw the technology group gravitate towards a process that he thought was dumb. He didn’t force his opinion down their throats; he let them have it their way. Note a subtle difference: he was NOT convinced himself; he merely allowed his people to make what he considers a mistake. This was quite eye-opening – by focusing on the assumption I made and precisely targeting it, I gave him an honest chance to convince me that my assumption of his stubbornness was wrong; instead, he reinforced it.

I encourage you to do the same the next time you’re interviewing someone for your team. What could this person say to convince me that they’re NOT what I think they are?