At least a hundred times, I’ve wanted to find whoever coined that phrase, “Fake it until you make it” and scream in their face “Look at the idiocy I have to put up with! See what you started!”
Then, I calm down and realize that I have used that exact same phrase myself as — I’m not even ashamed to admit it — advice.
As someone who has survived the start-up wars for several years and is still here improving our product and growing our company, let me give you advice on WHEN to fake it and when to make it.
CONFIDENCE
You are doing a crazy thing. You are starting a company that may fail. It’s possible no one will buy your stuff and you will go out of business. This is particularly true in something like software development where it takes months to make a product BEFORE you can sell it for one dime. You are making a product that only existed in your brain and now you want someone to give you money to fund that development. There are a lot of crazy leaps we all take on a daily basis and we need to have the confidence we will learn to fly on the way down.
Assuming you have some skills, are willing to learn and work harder than you imagine, you have a chance to succeed.
DON’T waste your time telling yourself that you’re no Bill Gates, you’re not smart enough or you’re too old or no one will listen to you or the 1,001 other reasons people tell themselves that they can’t succeed. Just do it. After you’ve made your first game, sale, pitch or operating system – you’ll still feel like that! It will get better, though, gradually, until you are the one people are pointing to and saying they’re no AnnMaria De Mars.
So, yes, when it comes to confidence, DO fake it until you make it. Double your sales forecast and then sign on to do a reality show so more people hear about your amazing products.
TECHNICAL SKILLS
Maybe if you are the sole person working in IT at a chocolate factory, you can get away with pretending you know more than you do. The second you get around people who have some experience, you will be found out.
Here’s why. Say, you throw around a lot of buzzwords like ‘propensity score matching’, ‘regular expressions’ or MEAN (as in Mongo, Express, Angular, Node). At some point, you’ll run into someone who says, with honest interest, “Oh, what language do you use for propensity score matching” and you’ll randomly throw out “Perl” because it sounds good.
Now, I’m not saying it’s impossible to do PSM in Perl but it’s kind of like training guard squirrels as a security system for your property – there are a whole lot easier ways to go about it.
I have a lot more to say about this than one post so let me close with some advice.
A common tactic is to find out a little bit about the latest thing, whether it is Angular or React or Item Response Theory (which hasn’t been the latest thing for a while) or whatever and then casually throw that into conversation. Because it is new, briefly, people will be impressed that you know anything about Angular since it is used on only 0.1% – 0.4% of all sites, depending on whose statistic you read.
However, that is going to be very brief because if you are hired for a technical position, they are very shortly going to have you doing things like writing code, and then they are going to review your code because everyone’s code gets reviewed early and often. That’s how people make sure their code works as an integrated whole, how your team members learn from one another.
They’re going to see that the sizzle doesn’t match the steak and you will be found out.
How do you get a job then? Aren’t people always telling women in particular that they are too self-deprecating when it comes to their abilities?
It was recently suggested to me that we should have some kind of technical interview when hiring, like Google supposedly does. We’re not going to do that. We have problems that we want you to think about, puzzle over and solve, not jump up with the quickest algorithm under the highest stress situation. We don’t work that way.
My solution, if you want to convince someone of your technical skills, is MAKE something. The best hires we have made have been developers who talked about their last project, were proud of it and could give me a lot of details on what they did and how they did it. They weren’t faking it.
Speaking of making things, I have to get back to work. Here’s what we’re making lately.
Thanks, your clear and practical advice is appreciated. It certainly can be difficult to know how best to apply “common” sense.