Realistically, if it's equal splits, they probably each own ~5% of the company (By that stage, the founder shares can be down to ~20%)
If they are raising $175M, their dilution is probably in the ~15% range, putting their valuation a bit north of $1B.
So, each founder probably is worth, on paper, around $50M right now. Again, this assumes equal splits. It's possible that the CEO has more shares by virtue of assuming greater responsibilities.
If you are long US and/or the logistics portion of on-demand, digitally assisted marketplace economy, it's not a bad idea.
For example, it's impossible to invest in just AWS without AMZN's other business. However, AWS is far less susceptible to the current macro geopolitical instability than AMZN's retail business.
This is not entirely true. Yes, Ballmer made many mistakes, but he also architected one of the most sustainably profitable enterprise software businesses (on the heels of all MS software products we love to hate). These enterprise customers are more than knees deep with Microsoft, and deep account penetration bought at least 5 years for Satya to steer the ship in the right direction (giving up on B2C mobile, Windows obsession, etc.)
One of the most common biases I see in how we assess leaders is how we try to attribute success & failure to a single person at a discrete point in time (ex: Here in the US, the extreme Left claims Trump is taking credit for Obama's foundational effort for the economy while the extreme Right says it's all Trump). In reality, it is never that simple nor discrete but rather complex and continuous.
I have to point out that while their marketing copy claims that they want to know "as little as possible" about their customers, they have Segment's JavaScript tag on thehelm.com
I agree on both. Honestly, much of my long hours were due to my inexperience rather than supernatural productivity. If I were to do the same work with what I know now, I'd do it very differently with far fewer hours (probably).
That said, the point OP was making is that in a startup origin story, there's a significant perception gap between those who actually moved the needle and those who claim to have done so. Those who actually drove the bus and those who rode it. Time and again, I've seen the latter people take advantage of the relative reticence of the former.
It's probably more like, "relative to this guy who tried to kill my company early on and later claimed undue credit for its founding, this dedicated early employee surely seemed like she worked 20+ hour days and sacrificed everything for me."
>As a final note, I want to add that if anyone was a “cofounder” of TechCrunch it was Heather Harde. She joined in 2006 but she was in the trenches with the team until the very end, working 20 hour days, sacrificing her personal life and giving everything she had to make the company what it was. Heather never sells herself like Keith does, but she should. Unlike Keith, she helped build that company, and gave way more value than she ever took.
As someone who's also been an early employee, I totally see why Heather does NOT claim to be a co-founder. When you work your ass off alongside the founders, you learn two things:
1. Building a company is incredibly hard.
2. Nobody takes it harder than the founders.
Yes, I have worked hard. In the last six years, I always worked parts of my weekend if not my vacations (which were few and far in between early on). I pulled off all nighters as well as a last minute trip straight from work to close a customer. I fell asleep on my laptop answering support questions. There were many nights of dry tears and waking up in cold sweat from nightmares that were all too real.
But what I went through is a fraction of what the real founders went through. And I saw their ups and downs up close.
Startups are hard. Incredibly hard, especially for those who has to lead the ship from Day One. Early, dedicated employees see this first hand, thinking to themselves, "Man, I thought I had a good/bad day, but they are probably having it better/worse". That's why we never claim to be the "founders".
Programmers continue to discover and re-discover APL and array-oriented programming.
If someone is serious about array programming/APL and wants to make a lucrative career in it, study KDB+/Q/K. There's a small but active community around them.
Just to relate an anecdote: I used to be a fairly active KDB+ programmer in finance but left both finance and programming ~8 years ago. Just yesterday, I got an email from my friend who's building a statarb fund around cryptocurrencies. They were going to use KDB+ and offered me a job for "300-500k base with incentives"...
My friends clearly don't know that I now work in sales & marketing :D
Aside: Roger Hui, the creator of J, is a programming sibling of Arthur Whitney, the creator of K/Q and the founder of www.kx.com
As a product marketer, I have to say that the name is very unfortunate.
1. Sundown is the name of a Markdown library written in C: https://github.com/vmg/sundown. That Sundown is pretty widely known and used among Markdown implementers. As such, when/if the OP's project takes off, it is going to be confusing (for awhile).
2. Also, the name itself doesn't strongly suggest that it's an alternative to Markdown. Do recall that Markdown's etymology comes from "(HTML) markup". For the Markdown-implemented-in-C Sundown, the name worked because it evoked its relationship with Markdown. In this case, that's not what the project is about. If the intention was to evoke Markdown, then they should have kept the "Mark" part of it, not the "down" part of it.
I used to use KX/kdb/Q/K daily for several years. I wrote a full implementation of reinforcement learning (15 lines), a lightweight MVC framework (to show reports and tables in an internal webapp) and even a Q syntax checker (abusing table as a data structure to hold parse trees). Good or bad, for the longest time, Q was my "go-to" programming language.
Based on that experience...
1) Yes, but that's not huge by modern standard.
2) Q is a DSL version of K. As others have commented, K is a pretty clean implementation of APL, and Q makes K more approachable.
3) I have to agree here, but Q for Mortals makes up for it.
4) It is really fast. As we all know, a vast majority of us actually don't have terabytes and terabytes of data, especially after a reasonably cleanup / ETL / applying common sense. I suppose it helped that I worked in finance, which meant my desktop had 16GB of memory in 2009 and 128GB of memory on a server shared by 4-5 traders.
Finally, Q was never intended for general-purpose computing nor a widespread adoption. At least when I was an active user, the mailing list had the same 20-30 people asking questions and 3-4 people answering them, including [email protected] (= Arthur Whitney, the creator). Back then, I'd say there were at most 2-3k active users of Q/K in the world. Now that Kx Systems is part of First Derivative and has been working on expanding their customer base, perhaps they have more...?
>but it has serious drawbacks such as the time and CPU resources it takes for parsing and the lack of schema.
Ditto. And if you still prefer the schema-free approach of JSON but with faster encoding and decoding support across all common programming languages, take a look at MessagePack.
Unlike JSON, MessagePack is optimized for speed and encodes common data types efficiently. Unlike Protobuf/gRPC, it requires no centralized schema.
This article epitomizes the old adage: software engineers are terrible at estimating. I have absolutely no stake in Mixpanel, and it has its own flaws, but seeing something as misleading as this on the front page of HN means I have to write a clarifying, if not somewhat edifying, comment =/
1. Right off the bat, there's the cost of building all of this + maintaining it. Something like Mixpanel at scale requires at least two, if not three, engineers: one for client libraries, one for infrastructure (which the OP blogs about), and another for the web app (dashboard, real-time user stream, etc.) To be sure, not everyone needs all features of Mixpanel. To be really sure, nobody needs all features of any SaaS tools. But if you really want to compare apples to apples, then you have to account for these. To hire competent software engineers who can collaborate closely and maintain a complex piece of analytics software requires at least $100k per year, if not twice that based on locale. That's at least $300k and more like $600k right there.
2. The whole point of something like Mixpanel is to make analytics accessible to non-engineers. In their case, it's primarily product people and secondarily marketing/customer success. In any case, building an analytics/data product consumable by non-technical people is hard and takes way more than assembling a couple of cloud infrastructure together. If there's one reason Mixpanel is still in business, that's because of this.
3. Finally, the OP has a valid point which should have been highlighted more, if not to make their own biases more clear: Mixpanel's diminishing differentiation is dev shops/consultancies' opportunity. It is indeed incredible that a dev shop can build even a third of Mixpanel's functionality by leveraging GCP components. Mixpanel had to build a lot of its core backend systems from the ground up, including its original key-value store. Just this year, they fully migrated to Google Cloud Platform themselves, suggesting that there's really little room for differentiation among analytics vendors at the level of infrastructure components (Mixpanel's arch-nemesis, Amplitude, leverages Apache Kafka and various AWS components, most notably Amazon Redshift, heavily)
With all of this being said, one thing remains true: the most expensive cost of any software is people running them and the dependencies created around them. These may not show up as line items, but they sure are deeply embedded in your total cost.
We are looking for solutions engineers to help our global customers use their customer data better. We believe that businesses should own their customer data, not outsource to the Google/Facebook duopoly.
This is a job for you if:
* You have a technical background and interested in leveraging it to create high-impact solutions for customers: many of our customers are household names. The best candidates have a technical background (formal or not) combined with customer-facing experience (consulting, running their own business, etc.)
* You enjoy gnarly technical challenges around data.
* People describe you as resourceful, smart and empathetic (all three are important qualities for this job)
* You don't mind traveling: there will be a fair bit of traveling.
About Us:
* Series C, HQ in Mountain View, offices in Japan, Korea with dozens of remote employees
* Active contributors to open source: Fluentd, MessagePack, DigDag, etc.
* Great salaries and benefits
* We invest in our people: most successful managers have been promoted from within
Indeed. Quietly but surely, Apple is changing its corporate policies around developers. We used to never see Apple developers at conferences with an official affiliation, let alone having them onstage as a speaker. I once ran into an engineer at a Ruby conference in which the guy demurred who he worked for, and when he finally told me he worked for Apple, he had to remind me the whole "what I say does not reflect nor represent..." preamble. That was as late as 2014.
Great to see such corporate changes toward developer-friendliness.
I had a similar experience and decided not to buy high-end Android phones: the modular (or fragmented) nature of Android's ecosystem doesn't lend itself for quality end-to-end experience. This is not meant to be a knock on Android. I exclusively used Android for the last 4 years, and I like Google's software, the choices on hardware, etc.
However, when it comes to end-to-end experience, Apple's vertically integrated approach is simply better. This is one of the key reasons I switched back to iPhone recently: I just want my phone to work and to be taken care of when it doesn't work.
This is everything that's wrong about Silicon Valley: we perpetuate the false virtue of overnight success, a flash of brilliance and youthful vision when, in reality, it comes down to years of slogging along, many nights of crying dry tears and adapting to the changing environment continuously.
It's sad because every operator I know knows this yet succumbs to the myth-making "hack" because that's how you tell a "good story" that attracts much needed attention among media and the investment community. Traction, hockey stick curve, growth and all that jazz.
And to be fair, it's not entirely VCs's fault either. They have to deliver on their investment promises within a certain timeline. What's really terrible is that there's not enough discussion about this in the VC-backed entrepreneurship community to accept that this is the "game" that everyone has to play.
>Can you please elaborate on why you think BigQuery's streaming inserts are not particularly reliable?
I've heard this from many users through my work on Fluentd (in fact, many end up using fluent-plugin-bigquery because they don't want to deal with the minutiae of insertId and whatnot on their own).
>Separately, you can always use BigQuery's federated query capability of Bigtable.
Yes, and very few people understand what that means (I had to look up, and I am reasonably educated on GCP). This is not necessarily product shortcomings but packaging deficiencies that can be addressed with better product marketing.