Variants of the following original essay have been featured on Quora and Mashable .
Everyone keeps saying the culture at a startup is different from that at a large company. And, if you're adventurous enough to want to make the transition for the first time, you'll be curious about the difference at one point or another.
People who spend their entire careers in startups or large companies never realize the subtle cultural differences that exist across the border. And that's okay. Most knowledge is useless. This particular knowledge is even detrimental to your career. A person with large-company skills is often like a deer in the headlights at a startup, the same way a startup person is often anxious at a large company. There are no right or wrong values. What matters is if you're at the place you need to be for the stage in your life, and whether you're equipped to deal with that place.
I would not be surprised if marketing people had already polluted the Internet with "10 things every founding engineer should know" types of prescriptions. I haven't tried to look for these, because firstly, they're useless, and secondly, they're discouraging. They're useless because there is no complete set of things that define a startup. You often don't even know the set of skills necessary until a year after you've already arrived. The founders can't even tell you, because they're too busy figuring out what they don't know. And prescriptions are discouraging, because they're just a reminder that the larger set of skills necessary in entrepreneurship are unknowable in their entirety. In fact most successful entrepreneurs tend to figure out a working formula and repeat it over their careers. Things that work, only work for a while, and for some. How discouraging is that?!
But there's room for encouragement. And I have figured out a way to formulate it elegantly:
Sh_t that obviously failed once will likely fail again.
Which brings me to my General Theorem of Startups:
Success is learning how to fail miserably, then how not to repeat it, a sufficient number of times.
Now this is encouraging. And it will present the startup culture's alien resident with their first dilemma: how do I achieve my first miserable failure so that I can be successful?
The first day you arrive at your new startup job, armed with your big company experience, you will assume one of the two characteristics: First, of an egotistic hot-shot ready to show these inexperienced younglings how it's done at the successful place you just came from, or Second and more likely, of a timid impostor anticipating that these genius innovators and their cult leader will find you out within the next forty-eight hours.
As my algebra professor back in college would say at this point, WLOG! (meaning Without Loss of Generality) I can now solve both of these cases with one assertion: That your external reaction to either of these internal feelings of displacement will likely demonstrate itself in the form of coming out and sounding like an a#$hole in a moment most surprising to yourself. I know; I've done it. It's okay. We're all okay. It's reversible, as long as you're willing to focus on the tingling feeling in both of your toes right now, leave the embarrassing past behind and realize that life is made in the present moment.
By the way -- don't worry about being found out by the founders. At this very moment they're busy making their own mistakes. And theirs cost the same as yours, with a few more zeroes in front of it. You'll never find out about their mistakes for your own good. Believing in your leader is good for everyone -- it helps you sleep securely at night, and it helps them get through the General Theorem of Startups more efficiently.
The main goal of this article is to show you how to fail quickly inside your startup's culture. The faster you fail, the sooner you'll un-fail and get to success. This is also good for everyone: your success adds value faster to the startup which makes everyone better off. It will likely make you more likable by your colleagues, who are struggling with their own fail moments and need to see someone else get more miserable, then get back up on their feet. Most important of all, the moment you commit your first failure, you're no longer the outside alien. Welcome to startup culture!
Without further ado, voila, the many cultural faux pas at a technology startup:
IMO, the biggest one might be claiming absolute knowledge about anything that the other person has not yet expressed agreement with. In a tech environment, even if you're 100% confident about X being true, you express it with "I think X might be true" or "let's try it with the assumption of X and see if it works" so that you allow room for the possibility that others may contribute something you did not think of. (Hence, my starting the above sentence with IMO)
(See "Commitment Bias", "Irrational Commitment" and "Escalation of Commitment" )
For example, saying "... and that's the best solution for that problem" during an interview without taking a few seconds to ponder and argue it logically, or without claiming that it's plausible that you're wrong, is almost a certain way of slashing the odds quite a bit that you won't get hired. Even if multiple people interview you, that one interviewer will likely veto your getting hired adamantly during the consensus building phase. Even if you built allies during the interview, they will concede that their positive opinion of you was probably premature if you managed to claim you were 100% right in front of one of their colleagues.
A few other situations --
- In one word, "Inaction".
- Having a "drag" instead of a "lift" effect on the take-off momentum of the team. (See Lift to Drag Ratio ) This is evident by the attitude of either analyzing things to death (See Analysis Paralysis ) or being stuck in the "storming" phase of Team Building, effectively endlessly competing for control on whose idea will ultimately get considered for going forward. (See Tuckman's Group Development Model )
- Asking what others make.
- Comparing the startup with your ex employer or sometimes even mentioning her name in a reminisce.
- Winning an argument using the "experience" trump card.
- Biased favoritism if you're in a position of authority.
- Not participating in rotating weekend roles such as being on-call for production deployments. In general though, startups are more immune to bystander apathy due to their small size.
- Claiming that you're bored (which is okay) without suggesting an alternative project. In general, complaining without suggesting alternatives.
- Looking to blame someone instead of focusing on finding a solution when an emergency arises.
- Coming to work at 1pm and leaving at 4pm, while flying a remote control helicopter the entire time in between.
- Particularly in early startups, it's uncool to critique how flakey or hacky someone's work might be. In larger organizations quality of code matters, but in a startup you're putting together minimal functions quickly to validate theories, so speed is a priority over quality. Spending too much time "gold plating" a hack or criticizing someone for putting together "unmaintainable hacks" are both premature and eye-brow-raising.
- Making a technical decision based on a faith-based assumption that is not explicitly disclosed to everyone else verbally.
- Missing a deadline when you yourself estimated the time. (much worse if a repeated pattern)
- Refactoring code (especially when you break something) if there were no automated tests.
- Not being outspoken about being "blocked" when you can't get anything done because stuff from other people that you depend on aren't ready. (This is so that you're given alternative work and are not left idle, and also so that your dependencies gain transparency into the fact that they need to prioritize things differently)
- Expecting others to test your brilliant code for you. (See Moral Hazard )
- Breaking the build.
- Writing brute-force (badly designed) algorithms, even when hacky code (badly organized) is acceptable.
- Premature optimization or scaling (this does not mean you should start by writing Brute Force algorithms. You should just know that your specs will likely fundamentally change.)
- Abstraction and generalization of a solution for a wider scope of use cases before seeing a repeated pattern of need for those use cases. Generally expressed, a platform or an abstract solution should only follow a few similar killer apps or concrete needs. Joel Spolsky describes people committing this faux pas as Architecture Astronauts -- also see YAGNI and Overengineering
- Most Software Engineering anti-patterns , with a few exceptions that are made for those startups that are still before the product-market-fit phase.
- Hiring an employee because they're "hot" or because they "can introduce their hot friends" (Yep, I've seen that)
- Making decisions based on what the competition is doing instead of based on the vision and what recent technology breakthroughs have made possible (Also known as driving by looking at the rear view mirror)
- Making technological decisions based on investor advice.
- Mentioning the words "training" and "customer" in the same sentence.
- Any organizational anti-pattern
- Any project management anti-pattern
I bet you didn't know there were this many ways to fail. And these are just the ones I've managed to encounter in one lifetime. Imagine how many you'll encounter in yours!
However large the space of possible failures in your future career, just remember these parting words:
- Everyone is an a$$ sometime, including yourself. Stand up for the weak. Don't take BS. But forgive often.
- Failure is normal. It's expected. It's part of the realm. Startups are about "not missing out on opportunities", not "not making mistakes". Think about the tingle in your toes (that's a little secret to recovering your charisma) and laugh it up. Somebody else will be wearing the "broke the build" shame hat tomorrow.
- Come back and read this article. As your list of failures grow, so will mine. I hope I'll always be ahead.
If you liked this article, share it. Someone out there right now is feeling terrible about themselves and needs to hear that they're not alone.