Joel here. This is a really interesting point, I've thought about it a lot.
From the linked article:
"In Startupland, everybody should be working towards the same goal: that big juicy exit. That’s the only payday any CEO should be worried about (even though more than half of them will never get it)."
I can't agree with that, and this is a key reason I spoke with others in the team and we decided that my salary as well as other c-level salaries should be quite high at this point. We're not planning an exit anytime soon.
Until a day ago, my salary was $118,000. In the first year, my salary was zero and in the second year it ranged from $55,000 to $75,000.
We're at a point with Buffer where there's a massive opportunity, and I'm going into my 4th year now. At $2.3M ARR and being cashflow positive (revenues cover the salaries) we're in growth mode and this isn't investor money we're using to fund these salary levels.
I completely agree that in the early years this would be a big red flag. I think the further you go, the more that notion reverses. I've heard that it can be a red flag if the CEO is not paid enough.
Would love to hear any other thoughts here, it definitely was a tough decision to make and I'm glad that by putting this out there we get all this valuable feedback.
Like you said, you are in growth mode. To me, growth mode means reinvesting as much of the profits as possible back into the company. Paying yourself a large salary during this time is the same as taking money off the table.
There are some good reasons to take money off the table, like paying back personal debt or supporting family members. But paying yourself more because you're the CEO doesn't seem like a good one, because your equity position is so significant.
If you don't have a good reason to take money off the table, it signals to employees and investors that "Joel thinks the money is better spent going into his personal bank account vs. making the company's equity grow in value." That sort of logic doesn't work in a startup that is targeting high growth, where employees are hoping to receive some sort of payoff from their equity. Moreover, it casts doubt on your judgment in capital allocation, which is one of the most important responsibilities of a founder / CEO. *
Obviously, all of this logic falls apart if you're not working on a startup. Low growth businesses that have achieved much of their potential are a totally different story. But you aren't starting a restaurant. Even Uber, at its $4B valuation, is giving compensation packages that are weighted towards options vs. salary.
We're not planning an exit any time soon, and are in growth mode, and we, the founders, take salaries slightly below the company average.
Why? Fairness. Our employees produce value, and we pay them justly for it. Excess value is retained in the company, and used for growth. The company, whether or not we choose to exit, is an asset owned by us, the founders. It's not a liquid asset, no, but it can be used for secured debt (i.e. borrowing against the value in the company), should we choose (we haven't).
We've been cashflow positive since day one and have revenues somewhat higher than yours. We've never taken investment.
For the first three years, my salary was £6k. Just enough to afford to eat and live in a squat. For the next three years, it was £22k. For the last two, it's been £30k. Our highest paid engineer is at about £60k basic - and we're not in London or a big city.
I guess at the end of the day it's a cultural call, and a personal one, but from my corner, I wouldn't be comfortable earning more than the folks who're doing the on-the-ground production, as we're not here to earn salaries, we're here to grow value.
Some of you might have heard about our security breach on Saturday. I just wanted to leave a quick note and clarify that this MongoHQ security breach was the method used to obtain our users' access tokens, which led to the wave of spam on Saturday.
This is a key final piece of our investigation which brings it back full circle. I'm very happy that we have been able to gain the full understanding and can be confident there is no backdoor.
I want to be clear that this is still our fault. If access tokens were encrypted (which they are now) then this would have been avoided. In addition, MongoHQ have provided great insights and have much more logging in place than we have ourselves. We’re also increasing logging significantly as a result.
Buffer security breach - October 26, 2013 [1]
MongoHQ security breach - October 28, 2013 [2]
But the Buffer security breach was via MongoHQ, so MongoHQ has likely had the issue since at least the 26th, and probably earlier, since the attackers had to have enough situational awareness to target Buffer. I guess my point is, MongoHQ likely had the issue for a while and it went undetected.
Joel and Josh have it right, we found the actual breach yesterday. You also have it right, the breach happened before Monday. We're hoping to find reasonably conclusive evidence of a start date we can share with affected customers.
Hi Justin. To clarify, from what I understand, October 28 is the date MongoHQ detected this. They've provided us with the logs of database access, and unfortunately the queries leading to our spam attack on Saturday started as early as October 19.
I can understand that MongoHQ wanted to obtain the full picture here and not put other customers at risk by exposing this information before the situation was fully locked down.
Have you considered not outsourcing critical parts of your company to startups that are iterating fast and potentially breaking things? Could you share the reasoning behind Buffer choosing to store their customers' private data with MongoHQ, instead of your own secure infrastructure?
This is the elephant in the room and I'm surprised it hasn't been mentioned by any of the other comments.
When it comes to infrastructure as a service, it appears to me that there is an imbalance between the sensitivity of information entrusted to external systems on one hand, and the standards such systems are held up to on the other.
EDIT: case in point, on http://mongohq.com I can't find a single mention of the word "security". The language is all about ease of use, performance, scalability, disaster recovery, and low cost, but as far as I can tell not a single word is spent on what procedures are in place to safeguard your data from unwanted access.
While I can see your point of view, and the grandparent's, let's be fair. These are startups in a rapidly evolving, highly competitive marketplace and they have limited resources. If they spent months triple checking every dotted i and crossed t they might never even launch, and there'd be no company.
Like everything in software it's about tradeoffs. Maybe they erred a little too far on one side of the curve, so let's learn from that. But it's unfair to expect startups to be in the same league as banks security-wise. Do you have any idea how much a good pentest costs?
As a founder of another startup (octocall.com) choosing to host our database with another company (postgres, hosted with Heroku) the decision is a simple one: You trade infrastructure management complexity for a monthly fee. Especially when you're starting out, the team is small, and time is much more expensive than whatever your database provider is charging you per month.
It's a great trade-off for most early-stage companies, because managing databases is hard. I'd rather leave it to the experts who specialize only in managing databases. You and your product team have a thousand and one other things to think about other than managing your database. Your provider may end up making mistakes, but that's part of the risk you take.
Security breaches are a mess for everyone involved, and we're in relatively new territory here in the Infrastructure As A Service space. Overall, I have little doubt that IAAS overall is a good thing. As an industry, we'll learn and improve on how to deal with all things "security", but we're clearly not there yet.
That's sort of a loaded question, no? A database is, in one way or another, critical to almost every business. I don't think that means every business should build one in house.
He's not talking about building the database, he's talking about hosting the database. And he's not claiming you shouldn't use third-party hosts, he's suggesting restraint in who you choose, in waiting for a track record to accumulate.
Security-after-the-fact is actually +EV just like certain risk distributions are +EV in finance. Companies must balance where they want to be in the secureness spectrum against the investment cost to get there and it seems that high grade security isn't worth the opportunity cost for a pretty big class of companies and customers.
Seems like they're pretty clear that they're still culpable for designing a system that relied on the trust of a 3rd party vendor to protect user data.
They waited until after MongoHQ made their own disclosure, and all evidence (including comments on the post) point to a fairly good working relationship between the two.
I'm sure both parties wish this hadn't happened, but I don't see any bus throwing...
Hi Joel, any thing you would recommend other devs who're connecting with facebook or any other social media API to look into? maybe you can share what you guys have learned reg: security and how to do it better from this
The best thing we've learned here is to enable a setting Facebook has called "Require AppSecret Proof for Server API calls". They actually have a lot of great security features which we've not been making use of.
I think considering the gravity of the situation, you and your team has handled this nightmare pretty well so far. Any of us who write software could end up in a similar situation - be it caused by a small configuration mistake, a slightly out of date 3rd party library, or a skilled, determined attacker.
When I see a local credit union site written in VBScript get hacked, I don't worry too much because it was probably riddled with SQL-injection bugs that any script kiddie can exploit. However, I know that you guys take data security seriously (you and I Skyped a while ago) and yet this happened. That's what worries devs like me the most.
I think it would be very helpful to us all (including many of your tech-savvy users) if you would write a detailed blog entry describing what actually happened and how. I believe you're encrypting tokens now but how did they get exposed in the first place? Was it a framework issue? Unhandled exceptions? Wrong chmod on a log file? New employee hooking up trojan'ed PC to your internal network? Here's hoping you feel comfortable in sharing.
Sorry this has happened, that's not good at all. I know that a lot of effort goes into getting in touch with us (or anyone else). There was a time when I was personally handling all the hiring, and I struggled to get back to everyone on top of everything else I was doing. We have a much better hiring process now and we've committed to responding to every email. Sorry again that you had a bad experience here.
Sorry about that awful experience we caused there. We definitely had a period where we simply struggled to respond to everyone. We honestly get about 100 emails from this HN listing. When we were just a few people, it was hard to keep on top of. It's a poor excuse, and we're fixing it now (we genuinely get back to everyone now). We didn't handle this well for quite some time, though.
Use resumator or one of the other cheap apps for handling this. For most people a canned response is absolutely fine, it's the no-response that ticks people off.
We do make sure to respond (and provide feedback if asked) to everyone who applies. The issue that we're working on is our response usually comes 2-3 weeks after the initial submission.
Glad you asked this, it's something we're constantly pondering. Right now the answer is yes, though we don't do it ruthlessly and our overall philosophy is to show that we truly care about everyone involved. We ask the team member if they feel it's appropriate, rather than forcing it. We've actually not lowered someone's salary in this way yet, though it seems sensible that it would happen.
The fact is that the living costs (largest chunk being accommodation) varies so drastically, that it feels hard to justify having the same salary and basing salary purely on skill, with the assumption that location truly is a choice and people have chosen to live somewhere cheaper. We have people who end up paying $2,500/mo rent and others where it is more like $800/mo or even less.
In addition, we always want to pay people more if they choose to move somewhere more expensive, it seems unfair if someone gets used to a salary in one place and suddenly they move somewhere much more expensive, and we don't help them out.
> with the assumption that location truly is a choice and people have chosen to live somewhere cheaper
That's a terrible assumption to make. People often live where they do due to obligation to others (family usually). I would never work for a company that would consider cutting salary because they moved to a lower cost area. I also know several people that have quit a job rather than relocate to a lower cost part of the country with an employer as the relocation also included a cut in pay.
To be clear, we are agreeing with each other. I think that is an incorrect assumption, too. We consider each case very carefully, and often don't cut the salary (it has happened more that we didn't cut salary).
That said, it is very easy here in the comments to argue how bad it is to cut the salary when someone moves to a cheaper location. However, the flip-side of the same coin is what about when someone moves to a more expensive location? Should we then say "this is the fixed salary and you choose where to live, and if you move somewhere more expensive that is your choice"? I don't think that is fair. So the other side of the coin of "salary goes down if you move somewhere less expensive" is that we increase salary if you move somewhere more expensive. We've done this for people and it is highly appreciated.
Our overall philosophy is that we want to help people to be wherever in the world they can be happiest and most productive. We encourage traveling and we have set ourselves up as a distributed team based around this value.
> However, the flip-side of the same coin is what about when someone moves to a more expensive location? Should we then say "this is the fixed salary and you choose where to live, and if you move somewhere more expensive that is your choice"?
I'd say that's absolutely fair, it's kind of the default expectation in my mind at least - I provide a certain value to the company as a remote worker, for which they pay me accordingly. (edit - as someone who just found a job via a HN jobs thread, I don't want to hijack this with a long response. Please see http://pastebin.com/4SrQJRj6 for my full response to this)
Buffer (http://bufferapp.com) - Anywhere in the world (we're a distributed team of 8 people across the US, UK, Hong Kong and Sydney).
I'd love for you to come join Buffer for the fun ride. We have over 700,000 users and are on a $1.5m+ annual revenue run rate. There are some super interesting challenges ahead, as we are looking to pass a million users in 2013. We are expecting even faster growth in the coming months through our mobile efforts.
We need help on 2 areas right now:
1. Android:
- Android is our second highest source of signups for Buffer, only
trailing behind Web which was our original platform.
- our users love the app, which has a 4.3 rating on Google Play.
- the app has 100k+ total downloads and 3k daily active users.
- we work with Google Play, Kindle and Blackberry stores.
2. Full stack:
- we get 1,500-2,000 signups per day on the web
- we have 170,000 weekly active users for our Chrome extension
- 4,500 API clients. Most popular: Feedly, IFTTT, Pocket, Instapaper
- we ship to production multiple times a day
- we have a data-driven process, with Einstein, our custom
built a/b testing framework
- ideally, experience in: PHP (Codeigniter)/Python, MongoDB,
Backbone.js Javascript, CSS, HTML
We're a small team of driven hackers and happiness heroes (our support people). Just like you, we're excited and passionate about engineering challenges and have some interesting architecture and scaling problems we work on.
If you're interested in coming on board, you will:
- work closely myself on Product and Sunil on technical
architecture
- ship to thousands of users and iterate quickly
- work with our metrics team to make smart changes
- be friendly and comfortable talking directly to customers
on issues and features
- be a happy, positive-minded and kind person who has a great
approach in dealing with others
- be a Buffer user (would be awesome, it’s cool if not)
- be anywhere in the world, and if you'd like, you have help and
support from us to move to where you want to be
- have experience working with another startup before (would
be awesome, it’s cool if not)
Some aspects of Buffer culture that makes us a little different:
- we are totally transparent. We raised $450k, we currently
have 700k users and generate $125k/mo. Ask me anything else!
- within the company, all salaries and equity are open and we
have a formula for the distribution.
- we're all very focused on self improvement - we have daily
standups where we discuss our current improvements. This
could be waking up earlier, starting public speaking, blogging,
exercise, learning a language, etc.
- culture deck: http://www.slideshare.net/bufferapp/buffer-culture-02
Salary: 88k-110k depending on location (living costs) and experience.
Equity: 0.5-1%
If this sounds fun, let's chat. Send a note to Sunil (our CTO) about yourself, why you’re interested in Buffer, and any relevant links (Github profile, Android Apps, projects and background): thenexthacker@bufferapp.com
Great question. We have actually only ever raised the $450k seed. Our revenues are helping with our ability to grow the team and have salaries where people can feel that money is not a factor, and we can focus on the great opportunities we have. For example, our April revenue was $115k and we're essentially cash-flow positive (we're hiring aggressively and aren't aiming for profit right now). To answer your initial question, we didn't take any salary for the first year, then we took $60k for a number of months before gradually increasing further. We increased to the $118k figure just a few couple months ago, which was over 2 years after we had started.
I tend to agree with this. I'm genuinely on the lookout for a service to replace Feedburner.
Buffer is often called "just a cron job" and I can assure you much of the work is in scaling up "just a crob job" to hundreds of thousands of users (alongside all the other aspects of the product). So I know first hand that "building a replacement" is not the hard part of the task. I certainly want to trust that you guys can scale this up and be a reliable host of my feed.
Our current FeedBurner feed has over 600,000 subscribers (don't ask) most days of the week. We know the difficulties of hosting constantly-updating info that's requested once a minute by hundreds of thousands of users: http://feeds.feedburner.com/~fc/neosmart
From the linked article:
"In Startupland, everybody should be working towards the same goal: that big juicy exit. That’s the only payday any CEO should be worried about (even though more than half of them will never get it)."
I can't agree with that, and this is a key reason I spoke with others in the team and we decided that my salary as well as other c-level salaries should be quite high at this point. We're not planning an exit anytime soon.
Until a day ago, my salary was $118,000. In the first year, my salary was zero and in the second year it ranged from $55,000 to $75,000.
We're at a point with Buffer where there's a massive opportunity, and I'm going into my 4th year now. At $2.3M ARR and being cashflow positive (revenues cover the salaries) we're in growth mode and this isn't investor money we're using to fund these salary levels.
I completely agree that in the early years this would be a big red flag. I think the further you go, the more that notion reverses. I've heard that it can be a red flag if the CEO is not paid enough.
Would love to hear any other thoughts here, it definitely was a tough decision to make and I'm glad that by putting this out there we get all this valuable feedback.