Category: Uncategorized

Why Startups Should Build An All-Star Team

There are a lot of thoughtful and useful posts out there expounding the ins and outs of how to build a great team and what it takes to attract a great team. This recent post by Michael Karnjanaprakorn CEO of Skillshare is a fantastic example. There is a lot to learn and put into practice. But I’d like to take a step back, play devil’s advocate, and address why you need a great team at all.

Why is finding All-Star talent so important? Isn’t your time better spent hiring who you can and focusing instead on working hard and building your product and helping customers and becoming profitable? Isn’t the success of a startup more about the product and product market fit, than the team? Isn’t it more important to enjoy working with the people on your team?

Unconsciously it’s easy to think along these lines. Every founder would love to have an All-Star team, the All-Star team, and may even often talk about making sure that that next hire will be an All-Star. But the day-to-day reality is that customer requests, finishing that one last set of features to test product-market fit, or getting yourself out in front of angels and VCs feel like problems that needed to be addressed yesterday.

Recruitment falls by the wayside.

It’s not what you do once in a while — it’s what you do day in and day out that makes a difference

Effective recruitment needs to take a long view. Understanding why building an All-Star team needs to be a priority can help you justify spending more time on it everyday and can push you towards making it a habit.

Setting the pace

An All-Star team moves fast and sets a high pace of completing projects. Basic features do not become bottlenecks. The turnaround from idea to prototype to garbage or from idea to prototype to execution should be measured in hours or days not weeks. (Tasks should be broken up into subtasks that can be accomplished within a day.) All those problems listed above can only be truly solved when your team is able to adapt and execute rapidly. The importance of a rapid pace of progress can’t be overestimated.

Events and time compound

The more your team gets done, the more your team gets done.  This has two sides to it, external and internal. An All-Star team is so productive it positions the company to be ready to take advantage of the external opportunities that inevitably come along.   When you’re on your game and prepared, the universe literally seems to conspire to help you and open doors for your company.

Luck is what happens when preparation meets opportunity.

The flip side of this is about internal momentum and morale. Progress begets success begets progress, it tends to build upon itself almost exponentially.  Momentum, within a project and across initiatives, is such a powerful force. It feeds the team and an All-Star team feeds off the success of its members. Individuals see success and subsequently are driven to raise their own game; it’s no coincidence that humbleness and striving for improvement are also traits of an All-Star team.


The longer any project/initiative takes to execute, the higher the risk you take on. There are so many risks you face as a fledgling startup. Risk of a new faster, smarter competitor, risk of existing corporation entering your space, risk of losing that one star employee, risk of running out of money, risk of losing that customer who was supposed to vouch for you to investors, risk of plummeting morale, risk of the market shifting away from your product, risk of technology changing, and on and on.

Risk is like a pack of wolves. The longer you let them linger the more likely you will be ambushed by one of them. A smart, sharp, driven, A+ team will let your company recognize and outpace the wolves. Prioritize finding a team that can respond and execute in unison and on target.


Dare To Give Yourself The Opportunity To Win

Though not as well known as other founders, Dalton built a great product in picplz. Unfortunately for his team they were just unable to match Instagram’s growth. Dalton’s response to criticism here reads like an entrepreneurial manifesto. These thoughts can be viewed in a grandiose light and are thus easy to ascribe to. But only when you walk the path do you realize the truths here and the emotional investment that prompted these words.

Anyone reading this article needs to remember to never be afraid of putting yourself out there because you are afraid of failure.

I saw the market first, I created picplz, and I went for it. I was a huge believe in the mobile photo sharing opportunity, and I went for it with all of my heart. Clearly, picplz didn’t win, but I have ZERO shame or regret for doing my best.

When I read articles like these, which are about myself, my company and people that I know well, I can’t help but feel vitriol aimed at me for DARING to create, launch and raise funding for picplz. I am not clear on what exactly people want, an apology for trying?

The fact is, I saw the writing on the wall that we wouldn’t win early and pivoted out of photo sharing which I had ~90% of my series A cash still in the bank. It certainly seems like that was the right move, but all of this press makes it look like pivoting was the wrong call(?) The press I read is written in such a way that it assumed that the A16Z investment is dead and my entire company should just be written off to zero today. That is bullshit. If I started to take press like this too seriously I might as well just dissolve my company and stop coming into work.

I say this to the hn comminity: never be afraid of failure. No one knows what will happen. All of this arm-chair quarterbacking is a waste of time. Stop reading this kind of crap and instead put your energy into doing your best work. Sometimes you win, and sometimes you lose, but if you give yourself the opportunity to win enough times, you WILL be successful.

Dalton Caldwell, Founder of picplz

There is so much good advice packed into these few paragraphs. Often the smallest ideas grow and grow into a larger vision, and big vision companies with vaults of cash crash and burn. He’s right — no one knows what will happen. But this fact should never stop you from trying. The unknown outcome is what makes this adventure so exciting.


Steve Jobs On Intuition Versus Rationalism

Steve Jobs delivered products that seemed like they had been beamed in from the future. While a lot of decisions at Apple are based on cold, hard data and facts, the overall vision and user experience that Steve imagined was one drawn from an intuition, innate and plugged in to help pull humanity in to the future.

This entire post might come across as Bohemian but I love this excerpt from the biography Steve Jobs by Walter Isaacson.


Coming back to America was, for me, much more of a cultural shock than going to India. The people in the Indian countryside don’t use their intellect like we do, they use their intuition instead, and their intuition is far more developed than in the rest of the world. Intuition is a very powerful thing, more powerful than intellect, in my opinion. That’s had a big impact on my work.

Western rational thought is not an innate human characteristic; it is learned and is the great achievement of Western civilization. In the villages of India, they never learned it. They learned something else, which is in some ways just as valuable but in other ways is not. That’s the power of intuition and experiential wisdom.

Coming back after seven months in Indian villages, I saw the craziness of the Western world as well as its capacity for rational thought. If you just sit and observe, you will see how restless your mind is. If you try to calm it , it only makes it worse, but over time it does calm, and when it does, there’s room to hear more subtle things — that’s when your intuition starts to blossom and you start to see things more clearly and be in the present more. Your mind just slows down, and you see a tremendous expanse in the moment. You see so much more than you could see before. It’s a discipline; you have to practice it.

Zen has been a deep influence in my life ever since. At one point I was thinking about going to Japan and trying to get into the Eihei-ji monastery, but my spiritual advisor urged me to stay here. He said there is nothing over there that isn’t here, and he was correct. I learned the truth of the Zen saying that if you are willing to travel around the world to meet a teacher, one will appear next door.


It’s rare to find such a blend of eastern and western philosophy on the job, in leadership positions, and in life in general.

Specifically, engineers are taught and trained to be objective and completely rational, relying on unit tests and TDD. Even CEOs, marketers, “distribution hackers”, and PMs are taught to focus more and more on lean methodologies, A/B testing, hypothesis testing and the resulting data.  There is no doubt that these qualities and approaches are necessary to build a successful product.

But when thinking beyond the next bug fix or the next release, when thinking about a new product entirely, a new startup, or envisioning a new way of doing things, you’re never going to have all the data to make a completely informed decision. Intuition can be a powerful force in choosing which path to take.

The intangible, the unquantifiable, and the unmeasurable have a place in this world.

I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success… such emotions make a man forget food, sleep, friends, love, everything.

Nikola Tesla

Continue reading

Hacking Growth To Your First 500K Users

Engineers are used to solving problems using a certain approach. Generally it can be defined in the following way: 1. Precisely define input and output requirements (let’s set aside performance, non-functional, etc requirements aside for the purposes of this post) and 2. Iterate in a deterministic way until your approach (algorithm) achieves Step 1.

The key here is that this approach is largely deterministic. Software is driven by cause and effect. Engineer says, machine does. (As we all know, almost to a fault. If only the machine could tell us how to do what we are really trying to get it to do!). We know that if we tell the machine to do something it will do exactly that. Furthermore, if some piece of code fails once we can be fairly certain the code will fail again in the exact same way.

In this way, humans are very different. And this is part of what makes marketing and growing the user base of a product so challenging. While overarching patterns in human behavior may be identified, on a day to day basis we have no idea who will respond to a certain product or promotion positively. We can’t even say for certain if the same person will respond the same way to the same product next Tuesday.

To have your product capture the attention of as many people as possible, and as many types of people as possible, and to grow your number of active users, you need a multi-channel approach. Some efforts will fail miserably, while some will succeed for no obvious reason, while others will succeed after a quirky fix to a campaign. The human mind is not so deterministic. You need to take the time to understand your users.

I came across this slideshare that highlights some of the wide-ranging, far-reaching efforts necessary to grow your user base. Unlike in engineering, the relationship between cause and effect is not so clear when managing users and user growth.

Building Relationships With VCs

Building a relationship with a VC or angel is just like building a relationship with anyone else. It needs to be fostered and it takes time. Above all, time to build trust and respect, and time to build a sense of how each of you approach problem solving, and how you work together when problem solving.  Along with these things you get to figure out if you actually like the guy or girl enough to be a passenger on your startup rollercoaster. I pulled this simple yet helpful list from a PandoDaily post written earlier this year by John Lilly.

John Lilly is a partner at Greylock Partners. Prior to Greylock, John was CEO of Mozilla, makers of Firefox.

Talent Wins Games, Teamwork Wins Championships

In his autobiography Rare Air: Michael on Michael, Michael Jordan talks a lot about teammates and teamwork. One page I distinctly remember has a picture of Jordan on the court in his red home jersey bent over with his hands on his knees, and Scottie Pippen is standing next to Jordan with his hand placed on Jordan’s sweaty, shaved head . It was a picture taken by acclaimed photographer Walter Iooss Jr. during the heated NBA playoffs in the early 90s and it tells a thousand words.

There’s a weariness in their body language, they are exhausted or very close to it. But there is also a sense of determination and connectedness, a feeling between the two players that they are going to fight through the challenges in front of them together and as a team – that they would fight together. Jordan obviously carried the team, but he was never alone, it was as a team they won the championship that year and for so many years after.

Another paragraph in the book quotes Michael while he talks about his pick-up games he’d play during practice or on the blacktop. He always played to win, no matter the stakes, no matter the players, so high was his competitive enthusiasm. He said, and I paraphrase, “Give me a teammate with talent or give me a teammate with heart, and I will choose the teammate with heart every time”.

Talent will take one only so far, and relying on talent alone can often lead to excess ego. Someone with heart is usually someone who takes on any role for the team to succeed, someone who admits they don’t have all the answers, learns from others, and is hungry enough to be coached. Someone with heart has an internal fortitude to give that something extra when success is on the line. With heart comes determination and perseverance.

The photo of Jordan and Pippen embodies this sentiment. The Chicago Bulls were smart and lucky enough to build such a team around Jordan.


Building a startup requires people of similar character, especially at the founder level and with early hires. In order for a startup to grow and flourish, you need teammates willing to take on multiple roles, put in long, hard hours, and absorb and learn new things.

I don’t mean to berate talent. Talent is so important, critical for success and talented people are hard to find. But talented people with the determination and perseverance to run through walls with you are even more difficult to find. They separate the wheat from the chaff.

Your System Is Defined By Data. Engineer Accordingly.

Data used to be the realm of scientists, researchers, and mathematicians in government institutions, universities or massive corporations (think banks). Even in the latter case, and still today, data is often buried under layers of infrastructure and protocols.

The internet and increased bandwidth/accessibility over the past decade gave birth to the democratization of data. Okay, democratization is a big word, but you get the point. Data is being generated everywhere in various forms and is being collected and analysed by anyone who desires to do so.  Even governments are opening up their troves of data to the public with the goal of greater transparency and efficacy.

In order build 24/7/365 web-scale applications on top of this data, we need to think about data in a disciplined way. The system does not stand alone. Data is part of the sytsem. Testing and measuring the system’s response to different types of data and/or increased loads of data requires a framework that informs the engineering team.

To that end, here are eight parameters that should be accounted for when building systems that deal with high volume data. These are things to think about up and down the full stack, not just the “back-end” or the “front-end”.

1. Total data size.  This is the amount data the system reads and writes while operating.  The proportion of data read to data written varies among systems. A site like the ostensibly performs many more reads (serving articles to each visitor) than writes, while an email application may need to handle more writes when accounting for spam. Some systems can generate massive amounts of secondary output such as log files. The growth of these outputs should also be taken into account.

2. Growth and change. How fast is data added to the system? Can older data be edited? Can data be removed? If so, how often do these types of transactions occur? Knowing how fast your data grows and changes is critical to understanding system performance and tackling scalability. Set up an internal testing component that simulates increasing data loads and run your system against this to see how it responds to different operations.

3. Temporal axis. Almost all data has some temporal nature, whether it’s a publication date, location timestamp, or time of last access. The system often needs to handle data differently depending on where the data lies along the time axis. For applications such as email and to an even greater extent on Twitter, older data is less frequently accessed. Conversely, users of Facebook very often look at pictures taken months or years ago. This is even more true with Timeline. Data must be stored with these access patterns in mind.

4. Network vs Disk vs RAM vs CPU. I’ve stated these in a specific order, you should know why. To borrow and mutate a common phrase — Know thy system. One of these four components will be your bottleneck as the amount of data grows. A bottleneck at the CPU indicates that your algorithms and processing is slow (perhaps you’re doing a lot of compression or maybe you’ve nested one too many for loops). Conversely you may have an “I/O bottleneck” where the system spends most of its time fetching data from disk or over the network. In this case maybe you’ve missed an index on a database table or maybe you need to think about distributing your data to increase read/write throughput. Think about whether you should be bringing the computation (“CPU”) to the data rather than trying to fetch large amounts of data to a processing component.

5. Throughput. Throughput is defined by two numbers: request size and request rate. Request size is the amount of data the applications reads or writes in a given call or user transaction. Request rate is how many transactions occur each second or each minute. Request rate is defined by the number of concurrent users and the distribution of activity levels across those users (from power users to casual users).

6. Consistency. This becomes more of an issue when dealing with distributed data. One machine or storage unit may be written to with the most up-to-date data, but the other storage units need to be updated as well. Different storage systems tackle this problem in different ways. MySQL Cluster uses the two-phase commit which has long been in use but gives up some availability (MySQL Cluster assumes some level of redundancy). The recent NoSQL movement sacrifices consistency for availability. The strategy used depends heavily on the application and use cases. In cases such as at an ATM, you expect your checking account to update immediately after withdrawing cash. In other cases, such as updating your Twitter profile, the consistency requirement is not as strong (although it does make for a frustrating experience when you still see your old profile up several minutes after editing it).

7. Latency. How fast does the application need to respond to a user’s action? When performing a friend search on Facebook I expect the friend to be returned within a second or two. When buying tickets to a show online however, I would expect this transaction to a take a few seconds longer. My tolerance for waiting is higher here. Your application should optimize for frequently accessed data, either by indexing the data or caching the data.

8. Physical and logical proximity. Data that is requested together should be stored together. When I visit a friend’s Facebook page, all of her pictures need not be loaded as well. Information that appears on a friend’s profile page such as name, profile pic, age, location, statuses should be stored close to each other so that these bits can be retrieved more efficiently. Sharding is one strategy used to keep commonly accessed pieces of data close together while simultaneously using the advantages of a distributed system.

“Big data” in and of itself is not useful. Bryce from OATV wrote a great post about “big data” and it’s shortcomings. However it’s still up to us to build the systems that can deal with this type of data and it’s up to us to then figure out what data is useful and what isn’t. To be hamstrung by your own system is not a place you want to be.

Engineer and test with discipline and you will be headed in the right direction.