Lessons from working for startups

When I saw that tweet this weekend it dredged up a bunch of thoughts and experiences that I’ve been wanting to put down on paper for a very long time. Why not now?

Over the past 6 years I’ve worked with 8 different startups in different capacities and pitched or met with countless others. I’ve been a founder; I’ve worked for equity; I’ve been a consultant getting paid cold-hard-cash; I’ve built prototypes, full products, and everything in between. I know there are a lot of more experienced developers out there, but even so, I think I have some things to share, and lessons I’ve learned from the good, bad and ugly of being a developer in a startup.

Startups aren’t for everyone

Every company is different, and from what I’ve experienced so far, the mindset and attitude of the bay area is different in a lot of ways from the NY tech scene. At the same rate, though, there are a lot of common things between most startups. In general the environment and process is much different from a large established company, especially in the early days. This means if you need rock solid stability of schedule, work cycle, direction, space, pretty much anything, startup life might not be for you. There is one constant in being involved with a startup and that is change. If you’re just a developer along for the ride, or a co-founder, change should be something you take in stride. A lot of this has to do with trust. Do you trust the people guiding this ship? Obviously this applies to any job, but is amplified when your livelihood is directly tied to the people you work with.

Don’t invest in an idea you don’t believe in

This should go without saying, but you’d be surprised when people don’t really understand what taking equity or options really mean. When you take equity as a developer (especially as a non-founder) what you’re actually doing is investing in the company in exchange for your skills/work. This isn’t something to be taken lightly – even if it’s a tiny piece. Take yourself out of the position of making the exchange for work. Assuming you had the money and opportunity too, would you give this company you’re money in exchange for equity. This goes beyond trust into the realm of belief. Do you believe that the startup you are investing in will actually be successful and provide a return on your investment? If you don’t believe that or have any doubts then as a developer you’re probably not going to work hard to achieve that goal.

This isn’t just about actualization, it’s about making good investments. Whatever you charge for your time, putting stake in something you don’t think is going to be successful is basically taking whatever money you would have made for that time and flushing it.

Get paid

If you’re a developer working for a startup theres no reason you shouldn’t be getting paid, even if you’re developer numero uno. Perhaps this means taking a slight pay cut from what you would be making at an established company in exchange for some ownership, but the general rule is you should be making more then enough to cover your life costs and at least enough that you’re not bitter towards those paying you.

I’ve done pure equity in the past and have pretty much completely sworn off of it. Unless you’re a co-founder, it’s going to be a very rare case to be committed enough to go the long haul without getting paid. And even if you are a co-founder, you should have enough savings to pay yourself, or think about raising some capital so you can.

If you’re approached by a startup to build their prototype or work on their app and all they have is an idea, they should pay you for your services. If this is the founders ‘side-project’ and/or they haven’t raised or put in any capital, thats a definite sign that you should get paid. Think about it – if they’re not willing to invest the capital to pay you, why should you invest?

Retainers Rule

Going along with the rule that change is one of the biggest aspects of being part of a startup, if you’re working as a freelance developer you need to structure your contract so it accounts for this. If the startup is small or just starting, working on a project basis is a bad idea as a rule. If you’re working to a fixed scope like “Working prototype of myawesomestartup.com”, even if the details are very well defined, what happens when the entire goal of the startup changes? Do you scrap your work? Do you ask for a ‘change-order’? Do you have to just suck it up and forget about getting paid for the extra time you put in? If you don’t assume this scenario from the start, it’s often awkward and painful to try to negotiate this post-change.

At the end of my last round of freelancing, almost all the projects I was working on were set up on some sort of retainer. This was great for me, because I had a definite amount of work and dollars coming in every month. It was great for the startup because they didn’t have to worry about getting charged extra or haggling over money every time they changed their minds.

I pitched every new job and potential client like this, and in the end it worked out great. If the client thought this was a bad idea or was so sure that they had everything ready from the start, I made sure to put in a clause or section that defined exactly what would happen and how much it would cost when they did want something different. (it always happened).

Get the position and job you want

This all comes down to the final point, that as a skilled developer the ball is really in your court. The key is to not abuse that advantage, but definitely make use of it to get the job that you want. The reason I hadn’t settled down into a full time job was really because it took this long to find exactly what I wanted. Paperless Post finally met my criteria:

  • Great people
  • Clear direction and strong motivation
  • A real business plan with actual revenue
  • Willingness to pay and reward good work
  • Dedication to Open source

It really shouldn’t be so rare to find this, but it really is from my experience. Your requirements might be different, but if you’re ready to take the plunge of investing a lot of time in a product or team it should always be doing the best to meet these goals. As a quick aside, Paperless Post is currently hiring in both NY and SF feel free to mention this post.

Working for and with startups has been uniquely rewarding for me, not just because I’m ballin’ but because I’ve learned more in the past couple of years then I ever could have hoped otherwise.

2 Responses to “Lessons from working for startups”

Patrick Says: #

Congrats for finding a startup you’re comfortable working in! A great team is very very key.

I’m getting into my 3rd startup project and have to say i enjoy the startup environments.

As a side note i’d like to thank you for an amazing SammyJS library which I use religiously for a few months now!

Jim Says: #

Really good post. I’m embarking on something similar and would really love to peek at your standard boilerplate for retainer arrangements. Could I beg you to drop me a line by email? Thanks!

About

QuirkeyBlog is Aaron Quint's perspective on the ongoing adventure of Code, Life, Work and the Web.

twitter/@aq.

instagram/@quirkey.

github/quirkey.

QuirkeyBlog is proudly powered by WordPress

Categories

  • No categories