What does it take to succeed at a tech startup?

Let’s level set first. This post is not about what it takes for a startup to be successful. There is plenty of (good and bad) advice about it already. It’s also not about what it takes for you to make the most money.

It’s about what it takes for you to grow professionally, be admired and respected by your peers and managers, and, above all, have a real impact on the product, the business, and, ultimately, in the benefit you are creating for your users and customers. It applies to founders and employees, managers and individual contributors, line-of-business or supporting functions, contractors or full-time employees.

My measure of success at a startup is pretty simple and based on three questions I’ve been carrying with me since early in my career: 1) Do most people who work with me today would choose to work with me if they were in charge of assembling a team (based on my competencies, ability to deliver, and my work style)? 2) Am I making things better than they were before I was involved? 3) Am I building a legacy of value for the people, the company, and the customers that will outlast me?

The reason I decided to write this post is that I’m often asked this by candidates: what it takes to be successful at Hiya? My answer has been highly influenced by the questions above and it has evolved over the years, from startup to startup, and it boils down to four attributes: self-driven & perseverant, outcome-oriented, adaptable, and velocity-focused.

Self-driven & Perseverant

“Grittier students are more likely to earn their diplomas; grittier teachers are more effective in the classroom. Grittier soldiers are more likely to complete their training, and grittier salespeople are more likely to keep their jobs. The more challenging the domain, the more grit seems to matter.” — Angela Duckworth, Author of the book ‘Grit: The Power of Passion and Perseverance’

This is an easy one and I don’t think anyone is surprised or unaware of it. You have to develop your own tools to be motivated, to start and finish your initiatives. Things might not come to you if you don’t go get it. Even when the activities come to you, they might come incomplete and, it’s not unusual for these activities to be in conflict with each other, lacking specificity or even lacking clear priorities and objectives.

You have to go beyond the “yes-man” attitude. Asking “why”, “when”, and knowing when to push-back are also a valuable part of being self-driven. If you just wait for the answers to come to you, you’ll find yourself adopting a can’t-do attitude and you can always find excuses for when things don’t get done and that it wasn’t your fault.


“Don’t tell me about your effort. Show me your results” — Tim Fargo, author

Outcome-oriented is the better child of being action-oriented. Action is about what you do; Outcome is about what you get. The effort (action) you put in is critical but just not enough. To be successful in a startup, one must focus on results above all, not how complete the spec was, not how many lines of code were written, not how many impressions the press release got or how many hours they worked.

If the intention is to get an improvement in the usage of a feature, achieving that improvement is more important than the analysis, creative ideas, the meetings, the sprint process, and all the talk. The opposite of outcome-oriented is to be a “feature factory”; it’s to create sophisticated Excel models of potential outcomes without ever talking to the customer; it’s to spend days or weeks in meetings and ideation sessions without bringing any feature to life; it’s to spend more time worrying about the engineering, testability, edge cases, accurate estimates, software architecture, monitoring, and analytics tracking of the feature than in the value the feature is creating for the majority of users; it’s to create elaborate go-to-marketing plan seeking the perfect splash.

Turns out the most outcome-oriented people are resourceful. They won’t settle for “I don’t know how to do it” or “we can’t do it with the team we have it”. They will figure out a way, often unexpected by their peers and managers, sometimes pushing the boundaries of comfortability for the company, often in clever and creative ways.


“The measure of intelligence is the ability to change” — Albert Einstein

You might have heard that “change is the only constant”. I can’t think of a better word to describe an early-stage or fast-growing startup. The job description you applied mention one type of work, by the time you start it’s slightly different, three months in you figure out the important work was Y, not X, and a year later you realized how “off the mark” the initial goal was. It’s not you. It’s not the startup. It’s the market, the world. Startups, the one still trying to figure out product-market fit or the ones growing faster than they can manage, are always experimenting with tools, technology, processes, and roles. This will happen independently of the people on the team. The question is if those on the team can feel comfortable with change, understand, and adapt to the new realities. Or, will they become anxious, frustrated or paralyzed?

You certainly heard of I.Q. You might have heard of E.Q. But have you heard of A.Q.? The Adaptability Quotient. You can understand someone’s ability to adapt based on how much they can unlearn(!), how much they seek to explore new ways of doing things, and how comfortable they are with not having the exact details of their role or their project. The more strongly held views a person has, the less adaptable they are.


“If You’re Not Embarrassed When You Ship Your First Version, You Waited Too Long” — Matt Mullenweg, founder of Wordpress

Although most of us know the definition of velocity in the English language (or in physics), in software engineering, it represents how much a team got done in a period of time. Rarely “velocity” is used in other business contexts, but it should. The difference between someone who’s velocity-focused vs. someone who’s not, it’s how much one focus on getting-it-done vs. getting-it-right. Wait, are you telling me that doing something wrong quickly is better than doing the right-thing slowly? YES! This is extremely counter-intuitive and requires some additional context.

The whole idea is that being right is better than being fast is based on a false premise. The premise that you know what right is and that “right” doesn’t change! Unless you’ve done it before (and tried, failed, succeeded), you don’t know. Actually, even if it worked before, it might not work again. It’s a moving target. This is particularly true in business and anything involving human beings. I’m absolutely not advocating for doing the wrong thing. It’s more about the precision we need to have before we consider the direction we are heading towards.

Being fast gives you a chance to try many different ways to find success.

I’ll give you just two extra things to read: One, about how art students focused on speed instead of quality delivered better quality pottery (!!!), and the other one about how a team of biologists at Unilever delivered a better solution to a nozzle-clogging problem through fast iteration and experimentation, beating the other group of people looking at it from a meticulous mathematical and engineering approach.

Want to be successful at startups? Be self-driven & perseverant, be outcome-oriented, be adaptable, and be velocity-focused.

Follow me on Twitter: @calbucci

You might also like…

[The unintended consequences of trying to do it all On my first job as a manager at Microsoft, the software developers on my team were spending too much time documenting…calbucci.com](https://calbucci.com/the-unintended-consequences-of-trying-to-do-it-all-32d481d28880)[](https://calbucci.com/the-unintended-consequences-of-trying-to-do-it-all-32d481d28880)
Marcelo Calbucci

Marcelo Calbucci

I'm a technologist, founder, geek, author, and a runner.