So you've been looking for startups to join as an early employee. You've an offer letter in your inbox. You like the numbers. You call to accept.
Stop. I've seen too many people – for better or for worse – rush to accept an offer without much consideration. Don't make that mistake. While most startups have great founders who are honest, have the right motivations, and properly value what you bring to the table, there are always the ones you want to avoid. But startups always paint a rosy picture, so how would you ever find out?
One key indication is that offer you have in hand. As an early employee, you should understand the larger picture surrounding the offer, before you make your decision.
The Basics
Salary
The amount of cash you get per month. Nothing exciting here.
Options
Options aren't stocks. They give you the option to purchase stocks at a price determined by the board called the strike price. This is usually low, or below market.
So let's say you have a bunch of options with 1 cent strike price, and the current share price on the market (or secondary market) is $1.01. When you exercise an option, you pay the company 1 cent to buy the stock, which you then sell for a profit of $1.
Vesting schedule
Your options have to vest. A vested option is an option that you own, and one that the company can't take back. This protects the company from employees running away with all the allocated options if he leaves pre-maturely, whatever the reason may be.
Your options vest according to a schedule, typically over 4 years, with a 1 year cliff. This means that 25% of your options won't vest till you're there for a year. And after your 1 year anniversary, you'll vest on a (typically) monthly basis.
Between the lines
There's more to consider beyond your offer letter. Judging an offer based on a raw numbers is meaningless. You need context.
How much of the company are carved out for employees? How much of the company are you really getting? What do investors really think of the company?
The more data points you get, the more informed your decision becomes.
The option pool
Startups typically have an option pool – a percentage of the company stock that's reserved for employee stock option plans. Your issued options are taken from this pool. Since this is a fixed pool, the amount you are issued typically depends on your role and the time at which you joined the company.
What percentage of the company, fully diluted, do your options represent?
Companies don't represent options as a percentage of the company in offer letters because there's no guarantee that they can maintain this percentage when dilution occurs (through funding rounds, for example).
That said, it's good to know about the percentage of the company your options represent. Make sure that it's based on the fully-diluted amount, which accounts for all stocks – exercised or not – that have ever been issued. This is a much better representation of your stake in the company.
There is no reason why the founders wouldn't give you this percentage, so be sure to ask.
Liquidation preference
Investors typically get preferred shares, which means that in a liquidity event, there are certain “preferences” attached to it. In some cases, you may see a “1x” preference, which means that in an event of a sale, the investors would get the invested amount back. Similarly, a “2x” preference guarantees them a 2x return on their investment, no matter how low the acquisition amount. In some cases, an unusually high liquidation preference could be viewed as a red flag.
Investors and the Board
It's good to know if the company has taken smart money or dumb money. Smart money is from investors who can offer strategic help to the company. Dumb money is from investors who offer little help beyond pure financing. Understand the rationale behind the founders' choice of investors.
The same goes for the board of directors. The board is in charge of the high level decisions of the company. Directors are appointed by the shareholders, and in a startup, it'll typically consist of the founder and the investors. If there are investors on the board, understand what they bring to the table.
I firmly believe that joining a startup shouldn't be about the money. And when there's a great fit between you and the company, these numbers will matter less – due to the larger motivations at play, and the openness and respect that is reflected in the offer.
It's always our personal responsibility to consider our financial prospects, and weed out the bad eggs. While I'm hardly qualified to give legal or financial advice, I hope this gives you a quick primer of what to consider before accepting an offer at a startup. You should also check out other great resources out there, including the very informative “Engineer's Guide to Silicon Valley” (hat tip to Kah Seng).
When evaluating an opportunity at a startup, especially the early stage ones, there aren't many data points available. So find out as much as you can. Talk to people. Understand your offer. Learn about the backgrounds of company and the founders. All this will go a long way in helping you make the right decision.
With the rise of “design centric teams”, there has been a lot of talk about the differences between designers and engineers. Sadly, they seldom are about anything constructive. But hey, aren't twists and conflicts just more entertaining to read?
The reality is far from a Mars vs Venus situation, as described by some. I have worked with many design teams – more notably IDEO, and more recently, one of the top designers in the Valley. I know what it takes to foster a close, productive relationship between engineering and design. And I know that it boils down to process and empathy.
Keep design ahead
Design should always operate ahead of engineering. Have a head start of at most two weeks. Any longer, and you risk having something that is outdated by reality by the time engineering starts. Interaction and visual design should be iterated and completed before writing a single line of code. This prevents frequent back-and-forth during development, which ends up being inefficient, and draining. In other words, churn.
Prioritize together
I can't stress it enough. Prioritization of features adds structure to your releases, reduces friction, and avoids overwhelming the team.
Plan your sprints with both engineering and design present. Give both sides a chance to be heard when deciding the priority of upcoming feature work. There's a lot less friction when the team understands the tradeoffs at play.
Once things are prioritized, stick to it. Emergencies aside, quick features, favors, or ad-hoc nice-to-haves throw off momentum.
Build a culture of empathy
A product team works best when engineers and designers not only show empathy towards their customer, but each other. This has to be driven by the culture of your team.
Being design-driven means treating design as a partner (and a leader) in the product creation process.
Design optimizes for best possible experience for the user. And that includes even the most subtle changes that make a product feel “just right”. Engineering makes that a reality by ensuring that experience is flawless under all scenarios. Sometimes, that means having to make tough decisions of implementation tradeoffs.
I believe the worlds of designers and developers are not so dissimilar as people think. Both cultures immerse themselves in technical professions, sometimes carrying a certain amount of elitism, but always with a passion for craft, self-betterment, and pushing the boundaries of what’s possible.
We should learn to appreciate each other's role. Start with chats over lunch. Have team-wide tech/design talks. Subscribe to Hack Design. Take lessons at Treehouse. It pays off.
At the end of the day, engineering and design work together towards the same goal – shipping a great product. We don't push against the other. We push each other forward. That's when the magic happens.
Ever notice that job listings always call for 5 years of experience? There is a reason for that, and it is arbitrary.
The critical difference between expert musicians differing in the level of attained solo performance concerned the amounts of time they had spent in solitary practice during their music development, which totaled around 10,000 hours by age 20 for the best experts.
Dr. Anders Ericsson first presented this concept in a research paper, which was later popularized by Malcolm Gladwell's book, Outliers.
In short, one becomes an “expert” after training for 10,000 hours. Or 5 years.
However, everyone eventually reaches 5 years of professional development. Does that make everyone an expert by default? While 10,000 hours worth of experience does give one a good level of familiarity with the subject, I wouldn't give out the title of “expert” that easily.
I believe it's how you spend those 10,000 hours that marks your level of expertise. A journey of rote learning gives you a very different level of understanding than a journey of critical problem solving. The progression of difficulty, the quality of instruction, the extent to which you push yourself; they all matter.
The process of learning can be hacked too. Dr. Ericsson, in the same paper, even alludes,
Experts have acquired domain-specific memory skills that allow them to rely on long-term [working] memory to dramatically expand the amount of information that can be kept accessible.
And research does point out that working memory is trainable. In other words, you can theoretically augment your domain-specific training with exercises like the dual n-back game, and speed up your development.
This is just another example as to why we can't generalize everyone's development. A “5 years of experience” benchmark is just arbitrarious. A “best expert” after 10,000 hours is likely a case of correlation, than causation. Ultimately, it boils down to what you do on the way to 10,000.
So what does happen when you reach 10,000 hours?
I remember that around my first 10,000, solving problems and building things became clockwork. Perhaps, to some extent, effortless. But I realized that there was so much more I wanted to learn, which I now could. I wasn't an “expert” by far. I had just leveled up, in a long hike to the top. And that's the way it should be. Doors open, and you start the next phase. That's all.
In the end, 10,000 is all but just a reminder for us to look back, reflect, and chart our way forward.
Startups can seem exciting, but when you consider tech jobs, remember the risks. When you picture success at an early-stage company, you may take inspiration from the money you will earn once the company “hits it big.”
On the other hand, choosing Microsoft to launch your career provides nothing but upside.
…
Don’t believe the hype. I admit I’m biased, but for tech jobs, Microsoft is your best bet.
Dear Kevin,
While I agree that Microsoft can provide fulfilling careers to many people, that's just a terrible response. Given Microsoft's history with startups, I never expected such condescension. (Incidentally, if the hype isn't worth believing, why bother fueling it with Bizspark?)
Top talent think critically. You need to present a logical argument. You don't convince people that you're cool by saying you're cool.
More importantly, you assume that great engineers are only interested in startups to “hit it big”. How about the chance to directly influence the product, disrupt industries, and ship daily to production? When people consider working at startups, there are a lot more motivations at play than just an exit.
Is Microsoft so desperate for talent that you would so willingly dismiss an entire segment of the tech industry and its brilliant engineers you crave for?
Follow up: I've spent some time at Microsoft, and have only good things to say about my experience.
My qualm isn't with the company, but rather, the content, approach and flippant tone of Kevin's post. Having previously worked there, that's not something I'd expect from the company, which is disappointing.
With this morning's launch, there has been a slew of articles proclaiming thattheiPhone 5 is boring.
Reviewers, quick to call winners and losers in the space, have spent the last few months lamenting that the iPhone doesn't offer more. Even some hard-core Apple fans questioned whether the iPhone can continue to trail blaze or if it's becoming a snoozer. One Apple employee recently confided he had been hoping the new device would have more dramatic changes.
In short, a longer phone with an interface that looks the same since 2007, just doesn't sound like progress.
I can't help but sense that people are missing the point. Let's take look.
No NFC. NFC is still at a nascent state of adoption. While it could be Apple's prerogative as a market leader to push for its adoption, the market may not be ripe for NFC just yet. The mobile payments space is still sorting itself out, and the success of platforms like Square would make NFC redundant.
There are bigger screens. As Dustin Curtis pointed out a year ago, phones with massive screens actually turn out to be less usable. While they make great selling points, the usability of the device worsens.
iOS is stale. Yes, it doesn't have the visual embellishments as its competitors. And yes, there are certain aspects that could definitely be improved upon. But iOS still is the most usable mobile interface out there; an interface that gets out of the way and gives us access to what we want, quickly and simply.
It's just longer. A radical new design doesn't make something better. Look back at the previous iPhones, each one really is an incremental update. With each new version, Apple iterates on what works, towards the goal of the ideal they set out to create in 2005.
Apple has never been about features for the sake of features. Features do make a phone stand out in the market. People do buy phones based on the longer spec sheet. But after a while, the gloss wears off and we only care about the things that matter to us.
In fact, over the next year, it is the innovation in mobile software that will impact users the most. Passbook for example, is a disruptive software play that doesn't involve a bet-the-farm hardware aspect to it.
The Apple and Google developer ecosystems constantly advance what we can do with a mobile phone. What ends up defining a smartphone is more than just hardware. Apple knows this, and they have provided a great piece of hardware for developers to take advantage of.
So the next time you see a new phone, think about what truly excites you about it. Is it the long feature list? Or how well it works and feels when your life?
Apple finely balances what we actually use, with what we think we'll use. And that's what the iPhone 5 is, executed to perfection. For now.
To some, this repetition is now boring. But I think Apple looks at it the opposite way: they’re perfecting their trick. – MG Siegler
Early stage startups aren't for everyone, and they certainly call for engineers with a certain set of qualities. Typically, engineers who have
Great technical breadth and technical depth.
An immediately applicable skill set.
The ability to learn quickly.
But it takes more than that to make an engineer a great startup engineer.
Focus
You can focus, and refocus, effortlessly.
In a startup, things crop up all the time that scream for your attention. And you have to respond – whether it's a bug on production, or a sudden re-prioritization of features. You keep juggling no matter how many balls are hurled at you.
Focusing on a single feature is easy. Having the discipline, attitude and agility to refocus spontaneously is hard.
Compassion
You have compassion for your users. Engineers traditionally tend to lack this, as layers of product managers and customer support form a pretty cozy insulation. At a startup, all that is ripped away.
It's easy to get entrenched in shipping a feature and lose sight of your users. And yet, you understand that getting people to use and love your product goes beyond the realm of engineering. Having this in mind frames your work, and keeps you constantly thinking about improving the product from your user's perspective.
Balance
You are familiar with the tradeoffs that are always at play – engineering optimization, business metrics and user experience. The right balance should, more often than not, err on the side of your users.
But that doesn't mean cutting corners. Instead, you figure out the best solution to achieve the right balance of the three at the very moment before iterating forward.
Responsibility
Responsibility is broad. To me, it's about your approach to your work.
A bug cropped up that you didn't cause? You fixed it yourself and didn't pass the buck. Finished a feature? You saw it through from deployment to fixes. In other words, you're selfless team player.
On the flip side, responsibility also includes your well being. You know when to rest and recharge, and that pulling 18 hour days is not a badge of honor. You know that the quality of your work will suffer, and your burnout will be a liability to the company. You know that your company can't afford to lose you like that.
Openness
Open communication is key in startups. You ask questions, challenge the norms, and hold on to your beliefs. And you will justifiably be proven wrong, disagreed with, and not have things go your way. But when that happens, you accept and absorb it with an open mind, just as the rest of your team would.
Startups, don't let your search for the stereotypical “rockstar” or “ninja” take your eyes off what matters. Great startup engineers go beyond amazing code and help you craft your product. And more importantly, they think for the team, and for your users.
This works great for now, but App.net will eventually have to have a degree of mass appeal in order to continually attract users to the service. And, not to mention, sustain itself as a company.
The quality and value of an asymmetric network is defined by who you follow, and who you can follow. Twitter is compelling because we can subscribe to updates of people who pique our interest. Let's face it, App.net's target demographic is a subset of Twitter users, so it needs to attract them over.
App.net has a great set of seed users – much like Quora did when it first started – which certainly helps. But it has to quickly leverage that, and figure out the right messaging to grow its appeal beyond Silicon Valley. Or risk becoming an empty vessel when the novelty wears off. As one who knows App.net's backstory, I do understand its vision. But will enough people have the patience, or understanding, to do the same?
App.net must position itself beyond just being a better ecosystem. It must illustrate relevancy in the face of existing social networks. It must first showcase value and utility over vision.
More importantly, App.net must let you tell the story of what it is to you.
We can learn a little something from In-N-Out Burger. Yup, that burger chain.
In-N-Out doesn't embrace the typical fast food marketing. No TV ads, no celebrity endorsements. Instead, they rely on the strength of their brand, which they protectvigorously.
The company is known as a “west coast only” chain that serves up one of the best burgers in the US. They have a stubborn reluctance to blanket the nation with stores in the name of quality. This elusiveness only drives up the mystique, demand, and cult following of the brand.
And recently, In-N-Out has started spreading the word to the rest of the world.
The Popup
No, In-N-Out isn't expanding internationally. They are, however, opening popup stores as part of a marketing campaign. Over the past year, such stores appeared – just for a day – in cities around the world. And they all ran on the same playbook.
1) Partner a local burger joint to house the popup store.
How does a humble popup work as a marketing tour-de-force for In-N-Out? Let's take a look.
Ripe markets
Popup stores opened in cities like Shanghai, Hong Kong, Singapore, Tokyo and Sydney. Now these major cities all have a couple of things in common; they are densely populated, and concentrated with
Locals and expats who have experienced In-N-Out first hand.
People who have heard about In-N-Out but have never tried it.
Potential visitors to a US city with an In-N-Out.
This is a potent combination. Combined, they help
Quickly and effectively spread the word on the ground.
Build up hype.
Pull a crowd. People started lining up two hours before the doors opened.
Buzz
At the In-N-Out popup store in Singapore, 600 people stood in line. Only 300 burgers were available. They were snapped up in 5 minutes.
From a practical standpoint, In-N-Out could have easily stocked up enough burgers for everyone, and opened for the entire day. But where's the buzz in that?
By selling out early, In-N-Out had people talking in the aftermath. They had the press – both local and foreign – churning out articles covering the insane lines and “record sell outs”. All while keeping up their trademark elusiveness.
Low cost
Opening a popup store doesn't cost much. The sale of the burgers immediately offsets labor, location and ingredient costs. Their net spend essentially amounts to a low key newspaper ad, flying over executives, and marketing collateral. In short, a very cost-effective, high return, marketing campaign.
Consistent branding
People would have readily paid ridiculous amounts for an Double Double Animal Style. Yet, In-N-Out kept their prices reasonable, and even comparative to other chains in the city. With that, they conveyed a consistent message to their customers – affordable, quality food for everyone.
The US saw over 60 million international visits in 2011. California alone hosts 13 million of them. That's a huge market to tap into.
[These events] are just one part of our efforts to promote and expand our brand as well as determine the best way to continue reaching out to customers around the world.
Dribbble’s inbox is filled with requests from companies wanting to run contests that leverage the creative pool to crowdsource their product needs. We tell them about spec work and let them know it’s not allowed on Dribbble.
In engineering – a similar value-creation industry – spec work is like asking a bunch of consultancies to build a significant chuck of your idea for free, under the guise of “an evaluation”. Or just imagine a 99designs for code libraries.
In such a world, the consultant optimizes for volume at the expense of quality, since unselected work costs time. The client ends up choosing from crappy solutions, without even realizing it. This just creates a lose-lose situation for everyone. That's why it's unheard of.
Spec work is a concept that fails the test of reality. I don't understand how spec work in the design industry should ever be considered acceptable, and I do hope that more take a stand like Dribbble has.
At times, we tend to over engineer and totally forget about our users. We have to balance engineering effort, metrics and user experience. Striking the right balance can give great results.
Mailcheck.js is one example. On one end, we can make users type in their email address twice. That's optimizing for the 10%, at the expense of the 90% who are typo free. And on the other end, you can engineer a fantastically great solution - predictive analysis, MX record checks, etc. That's exponentially more work for a marginal return.
Mailcheck was born out of analyzing email bounce data. We knew exactly what we had to solve, and the most engineering efficient solution naturally evolved. This resulted in a big improvement in metrics and user experience.
Simplicity goes a long way. Don't over-engineer your solution and don't prematurely optimize. Keep it efficient for engineering, and keep it simple for your users.
