271–280 of 462 posts
Earlier quoted context omitted.
So make sure you're hiring a hero and not a primadonna?
The difference between hero or primadonna can be environmental. When there are multiple experts for a department/tech stack, you get heroes. If the bus number is one, a hero risks converting to a primadonna.
I looked at it this way. The thing most engineers, hero's or not, want to work on is new projects and to build products customers enjoy. The last thing they want to work on is maintenance. In my last personally owned company, small as we were, the engineering team and I documented how things worked as part of what we did every day. We found that by having the inner workings documented so that anyone in the team could…
> Just having the system continually documented In my experience this is the hardest part. Can't count how many times my team started documenting and then slowly, for one or the other reason, the documentation became outdated. The cycle is: Meetings for communication -> becomes too cumbersome and time consuming -> implement policy to document things -> everyone start documenting (for a month or two) -> docs are not u…
It could have been really annoying but the product lead was extremely empathetic and that could be felt in any task discussion, and his attitude made me want to do it instead of making it feel like busy work like it has in other companies.
Earlier quoted context omitted.
Doesn't anybody remember how literally Whatsapp's founder wrote on one of the ejabberd mailing lists with something like "I just installed the server, please help me configure authentication" or the like? Retrospectively that has always colored my perception of how relevant technical aspects are for a successful startup (i.e. not much). Marketing (and viral, user-capturing & monopolist practices) are (sadly) much mor…
If you look at https://www.infoq.com/presentations/whatsapp-scalability/ though it gives a very different picture. Sure, the founding team may have tried to prototype without knowing full technical details, but they knew enough to choose software that could fundamentally scale towards the future, and they rapidly brought on fantastically talented developers with a hunger for optimization. You can't choose the right t…
They may have hired people later on (though this entire article is kind of showing that no, they actually didn't hire that much technical people). But by the time they even hired the first Erlang engineer they had already won over the European market. And for the record it was not precisely due to the quality of either their Android or iOS android apps -- the J2ME and Symbian clients had quite a following and I would even bet were more used.
Original Whatsapp was a disaster and this did not prevent them from gaining marketshare. You could basically login as anyone just by having their phone number (which maps to their JID) and defeating their XMPP obfuscation layer (some XML encoding, which was easily done due to the easily RE Java clients).
It was only later on (2011ish?) that they started getting somewhat serious, which coincided with them, already swimming in users (and money?), starting to get more evil (with a more hardcore stance against 3rd party clients).
My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…
My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…
Earlier quoted context omitted.
Ultimately though WhatsApp ended up with a billion users and 0 revenue.
Not true. They were charging $1/year from users in the richer markets. They could easily reach hundreds of millions per year in revenue if they followed this model.
The vast majority of people will leave your service if it goes from $0 to even $1. So no, I don't think they could "easily" scale that up.
My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…
This is why, after being both an engineer and a product manager (and VP of Product), and now a CTO of a seed stage startup, I’m fairly convinced PdMs are unnecessary. At least for the the type of company I’d like to build (WhatsApp as a primary example of that). Off loading the founders vision to someone else is a failure of both communication and org structure (at the seed-SB stage). People may not think hiring thei…
I wish more PM's thought like you.
My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…
Uh yeah, but it was only possible to have such a simple product because they reached mass adoption. Without network effects, you've got to differentiate and thus add complexity to gain users.
I looked at it this way. The thing most engineers, hero's or not, want to work on is new projects and to build products customers enjoy. The last thing they want to work on is maintenance. In my last personally owned company, small as we were, the engineering team and I documented how things worked as part of what we did every day. We found that by having the inner workings documented so that anyone in the team could…
The only way I've seen documentation get the priority it needs is if management mandates it as part of the release package on which developers' performance evaluations are based.
My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…
Doing one thing good is a thing in the past. Venture capital has pushed basically all start-ups into 100-feature shops