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.
What are the success rates of startups with N founders, where N is a positive integer, for each value of N?
This question assumes a simplistic and absolute relationship between the number of founders and the success rate, which is difficult to isolate in the contextual variable-rich environment of startups.
To get the best perspective, I encourage you to read the "Startup Genome Report 01: A new framework for understanding why startups succeed" published on May 28th, 2011 by Max Marmer, Bjoern Lasse Herrmann and Ron Berman with support of Chuck Eesley, Steve Blank and Fadi Bishara and in collaboration with Stanford University, shared under Creative Commons License:
It's a rather long report, but very enjoyable (for some) to read. It has a summary section, with "primary" findings (which I'm skipping) and "additional" findings, which I'll cite here because it's related to your question:
Sample size of the following statistics: 663 web startups
Founders that learn are more successful: Startups that have helpful mentors, track metrics effectively, and learn from startup thought leaders raise 7x more money and have 3.5x better user growth.
Startups that pivot once or twice times raise 2.5x more money, have 3.6x better user growth, and are 52% less likely to scale prematurely than startups that pivot more than 2 times or not at all.
Many investors invest 2-3x more capital than necessary in startups that haven’t reached problem solution ﬁt yet. They also over-invest in solo founders and founding teams without technical co-founders despite indicators that show that these teams have a much lower probability of success.
Investors who provide hands-on help have little or no effect on the company's operational performance. But the right mentors signiﬁcantly inﬂuence a company’s performance and ability to raise money. (However, this does not mean that investors don’t have a signiﬁcant effect on valuations and M&A)
Solo founders take 3.6x longer to reach scale stage compared to a founding team of 2 and they are 2.3x less likely to pivot.
Business-heavy founding teams are 6.2x more likely to successfully scale with sales driven startups than with product centric startups.
Technical-heavy founding teams are 3.3x more likely to successfully scale with product-centric startups with no network effects than with product-centric startups that have network effects.
Balanced teams with one technical founder and one business founder raise 30% more money, have 2.9x more user growth and are 19% less likely to scale prematurely than technical or business-heavy founding teams.
Most successful founders are driven by impact rather than experience or money.
Founders overestimate the value of IP before product market ﬁt by 255%.
Startups need 2-3 times longer to validate their market than most founders expect. This underestimation creates the pressure to scale prematurely.
Startups that haven’t raised money over-estimate their market size by 100x and often misinterpret their market as new.
Premature scaling is the most common reason for startups to perform worse. They tend to lose the battle early on by getting ahead of themselves.
B2C vs. B2B is not a meaningful segmentation of Internet startups anymore because the Internet has changed the rules of business. We found 4 different major groups of startups that all have very different behavior regarding customer acquisition, time, product, market and team.
I also completely agree with Ryan Lackey that there are diminishing returns on the number of founders above three -- primarily due to the network effect of the communication overhead, which is very expensive at such a fragile stage.
A small 2-3 founder team, balanced across different skill disciplines, well-positioned for learning from its mentor and investor connections, and not over-confident about its market positioning and IP, has the maximal chance of success. Deviations from this formula, depending on the variable, have drastic effects on the outcome.
A quick thought occurred to me this morning as I was taking the elevator up to the second floor to my desk at Adify: I feel a part of the family.
Today it's been exactly one month since I started here. Already most faces look at least familiar, if not friendly. I've had the chance to interview a few new hires and have an impact on the future membership in this family. And I know exactly my role, that is, what part of the product I'm engineering.
I read half of the book "Leadership and self-deception: Getting out of the box" by The Arbinger Institute last night. So far it's a great book and I highly recommend it. It's written mostly in a dialogue format and illustrates how little we get to know the people around us in our quest to advance in our careers. It argues that ironically, the key to career advancement is in getting to know people around us and treating them as equals on a very personal level, rather than as parts of our self-elevation machine that just happen to be made of people.
I liked people I worked with at Microsoft equally well. I still remember their faces and their kindnesses. The exact charismatic facial expressions of a few of them come to my mind when I read case studies of leadership in this book. But there was a fundamental difference: At Microsoft, the sense of unity I feel now didn't exist.
I'm going to have to resort to analogies to explain this better. A team is like a tribe: with its own culture, role structure and survival goals. When a small tribe is unleashed into the wilderness, their primary evolutionary purpose becomes tribe-, not individual-, survival. The resources in the nature are infinite, and so are the survival risks. Performing your duties in the tribe is not a zero-sum game. If you perform in such a way that you increase the productivity of the tribe, you and everyone else will feast more often. If you don't know how to handle your tools, it's in everyone's best interest to teach you voluntarily, knowing that when the roles are reversed, you will do the same for the common good.
As the tribe grows into a gigantic size, it faces new natural constraints. The resources, once virtually infinite, are now only as vast as the size of the tribe itself. While ingenuity will always lead to more production despite limited resources, the natural and physical constraints on resources put more pressure on individuals to be creative. Any lapse in the stream of visions for new ways of maintaining and increasing production will put more demand on exploiting the existing resources. The culture of co-operation, facing scarcity of resources, turns into the culture of zero-sum games. Gains are finite, and therefore scheduled. The tribe cannot grow faster than the nature will allow it to, similar to how the company cannot grow larger than the market itself. The scope of success is therefore reduced from the good of the collective to the good of the smaller groups inside the collective who compete with each other for scarce resources.
This is what breaks apart empires. This is why powerful kingdoms and unions have to deal with separatist revolutionary groups. When scarcity for all becomes the norm, minorities will spontaneously try to tip the balance of survival.
Let's get back into reality. When a company dominates the market, you see people hiding away in their offices, trying their best to outperform each other. It looks competitive and brilliant. It looks impressive, until you lift up your head and realize you have become one of them. You get to work a certain time of the day and you leave work exhausted after 10 or 12 hours to manage the other broken roles you have to play at home, as a friend, a spouse, a parent or otherwise as a balanced human being. You give it all, compete, get stacked, ranked, allowed to survive just to do it all over again next year. The culture of doing important things for the common good is replaced with the culture of doing unimportant but urgent things while hitting yourself against the walls of nature and waiting for something good to happen out of the blue.
One thing I really enjoyed about my life in Washington before I moved to Silicon Valley was the huge, tall and lush trees. I often felt lost in nature driving down Bellevue or up the Cascades. It's an amazing feeling, as if one is lost in the Fangorn forest of a Tolkien epic story. And in the end, I observe that as a human-being, I feel healthier when I'm a small part of an infinite nature. It's the chase we're all in love with, not the domination. In our evolution, we have always faced infinite resources. Our minds have developed into machines that cooperate with each other to build new tools to survive.
When our tribe population dominates the forest, when the cottages become town-houses and the duplexes become skyscrapers, we may need to move out to less explored lands; just to find a neighbor who wants to invite us in for a cup of coffee instead of going over the maintenance schedule. Our ultimate goal is to be happy, and our happiness is tied to a sense of being fit for survival, together as a group. Maybe it's time to jump back into the wilderness.
Handing off the technical side of a successful bootstrapped startup
The DNA of a product company, as determined by its founders and first three engineering hires, permanently decides its fate. The right hiring decisions do not guarantee success for the company, but the wrong decisions do guarantee permanent mediocrity.
A journey of a thousand miles begins with a single step.
Lao-tzu, Chinese philosopher, The Way of Lao-tzu
- Move deferred authority reference to the footer
Rule 1: Bad developers don't recognize the smell of other bad developers
Guy Kawasaki in his "The Art of Recruiting" post, quotes a brilliant Macintosh Division saying: "A players hire A players; B players hire C players." One of my colleagues words it another way: "The less you know, the more you think you know." That's why it's so much easier to come up with many examples of dumb people in power in that dysfunctional dead-in-the-water organization: They think they know a heck of a lot, and they're not shy to talk about it. They're a C player talking the talk of an A player. None of the merely good people can sense the smell of trouble, and believe what they see; the pointy-haired boss reaches the top of the pyramid.
gist: no matter how you measure and give feedback on performance, it is determined by how you compensate. Once you start paying decent salaries, you are rewarding the employee for showing up and producing visible output. In engineering, masterpieces are done when the engineer stays home and works on an interesting problem. They don't even show up. And important work is often invisible to marketing, in the same sense that seismic foundation work in a good building takes time and doesn't look like progress. The only way to get the right behavior out of a salaried employee is to have the right culture already established by prior hires at the nascent time when a large portion of their compensation was equity based, not cash based. Then, and only then, you have a defense line from shoddy work making its way to the invisible layers of the product where no owner has visibility into. Salaried employees not rooted in a strong culture will take risks with the architecture and product because they are protected from the business risks. The same employees do a fantastic job when their personal goals are realigned to elicit and command the respect of the senior gatekeepers of a strong engineering culture.
Rule 2: The real cost of design problems don't surface in the first 3 years
Software is complex - very complex - especially to stakeholders. The product must ship on time and budget; and sometimes a decent looking, bug-free and ahead-of-schedule product is a lot more appealing than one for which your engineer is begging for more time to "clean up" some mess. Software elegance is a long-term investment; one for which I have never seen a metric in any of my past workplaces. Time and space complexity are some of the metrics that are at least measured within the engineering team and used to defend a design. Elegance itself however, is a concept much harder to define. When a minimal level of effort is needed to understand your code or to extend it, and when in doing so, a gratifying feeling is experienced, elegance is achieved. There are financial consequences associated with lack of elegance: You're spending more money on more grunt work in crowbarring yet another feature into a framework that does not accommodate change, or for that matter, even maintenance. The longer elegance is ignored in an engine, the more it costs in the opportunity of having higher velocity. Elegance has a direct co-relation with the long term cash-flow of a software company whose biggest expenses are infrastructure and maintenance. Its positive impact is not felt when your star developer is putting his or her heart into it. And the consequences of lacking it cannot be blamed on a lousy developer because they're usually long gone when you first experience its impact. What should you do? Hire the best, and give them authority.
gist: Compensation is twofold. Boredom is your enemy. If you're challenging an engineer with re-work instead of forward improvement, you're only providing half of the compensation (Cash, not satisfaction)
Rule 3: Great developers get bored doing rework, even if you pay them well
gist: you're gonna need to give 20% time. Whether you give it or not, they'll take it. Make sure they can perform with 80% of their bandwidth.
Rule 4: An appealing competitor and a bored partner will cost you half of your property
Excuse the analogy. Great software developers are in extreme demand, even during the recessions and bad times. A salary, good benefits and lots of praise are necessary to keep your developers attracted. However, don't fall for the same myth that the typical New York financial corporation is under: these perks are not sufficient. A star developer is a dreamer. That little gerbil in his brain is turning the wheel, whether or not you want it to. Those dreams tend to be far greater than the typical startup company can typically afford, or the typical traditional company would typically care about. Your star developer is not usually yearning for more salary, but rather, for more freedom. If only he could make that one move that you're not approving of, but which would cut everybody's work in half. If only he could have a week of not having to do this boring task that you've assigned to him, so that he would completely automate it for everyone next week. Every recruiter that understands this wish is a winner: Your competitors are not luring in developers just by overcoming their fears of financial instability - they're also offering them more freedom to work on something they would love. There is a significant cost associated with losing the tacit knowledge that your star developer might take away with him. Even more significant is the very likely opportunity cost of doing so many other much more valuable things that you're not focusing on, by instead focusing on boring and redundant things that are boring your star developer. Sometimes you get a wake up call with a letter of resignation. Some other times you just slowly realize that you're still struggling with maintaining what you have, and your prime business offerings are on the next ToDo list of your competitors.