4,965 karma · joined October 8, 2008
tr at tern dot sh
So are https://example.com and http://example.com.
If you serve materially different content based on small differences, that's user-hostile, and common tools have no obligation to support you. Chrome shouldn't cater to sites that change behavior based on a www prefix, because the vast majority of users expect those sites to be the same. Hiding the prefix won't change their mind.
But if you're going to spend the money, maybe you could entirely fix the problem. You'd have to run the numbers!
If you wait, you get substantially more information. A company that makes it to a Series A has a much higher chance of succeeding, and you'll typically know that in your typical tenure of 1-3 years as a junior dev.
If you want to spend $10k cash on buying startup equity, at least call yourself an angel investor and go find a company that's willing to issue you a note that converts to preferred stock. It's too easy for a company to have a couple of missteps and wipe out most of the common stock value, even much later.
You are investing a couple years of your life in this. That's probably investing a couple hundred thousand dollars of opportunity cost vs a job at large tech company.
You have plenty invested. You'll do well if they do well. Spend your liquid investments in something diversified.
- sincerely, a moderately lucky person who has joined 3 companies before employee 15
In a world where people occasionally steal $100m, that implies a maximum sentence of ~1 year for stealing $1m.
The other professional problem that well-run startups have is that it's easy for early employees to feel like they're held to a different set of standards than the founders for professional growth. Essentially, founders are given chances to succeed in roles they never could otherwise, and early employees miss all the coaching and context that might help them succeed in similar roles.
Let's imagine I was a 26-year-old developer interested in startups. I have two paths:
- I found a company. I have the chops to hack something together with my cofounder, and maybe we make something of it raise a seed. We hire another couple engineers, and with a couple big logos in a good market, we raise an A. At this point, I've learned a ton about what makes a business work from other founders and I see (far too clearly) the gaps in my own knowledge. I hire some marketers / salespeople to work for me, and we keep making things work. At some point, maybe I choose to hire a professional CEO, and I stay on as CTO. I still have a lot of leverage in the company. I still go to board meetings.
- I join a company as the first employee, after they've raised a seed. I have good conversations with the other 26-year old founders over beer after work. I jump on the occasional phone call with customers and crank out features that they like based on that insight. We raise our A, though I'm still a software engineer since we only have 10 employees that all report to one of the founders. I quit seeing customers, because we hired a sales rep. We decide to hire management, and I'm considered for a line manager job, but we ended up hiring somebody externally. (She was awesome, glad we hired her, but I'm bummed I'm not reporting to the CEO anymore.) By the time we're 40 people, I don't talk to the founders much anymore, and I don't really understand what our bigger customers want. I don't have the influence I once did, and the codebase is too big for me to brute force that leverage through productivity. I start to look for another job.
There's nothing wrong with either story, but in the founder case, I was given a ton of chances and support. As an employee, I was given, at best, the support of a single manager while the company grew around me. This is fair, in some sense, but compared to the opportunities offered to the founders, it's far behind.
I'll share a model that's worked for me in the past. Before you even write the job description, define the 3-7 traits you need to hire against. These can be as fuzzy as "gets shit done" or as specific as "5+ years marketing SaaS to $100k+ accounts" or "is effective at resolving incidents while on-call." You need to be able to rate people on this. Binary is fine ("yes they can get shit done"). 3-4 levels is good (bad / good / total superstar).
Don't go overboard with granularity: you need to fit this all in your head for a couple candidates at a time when you compare them. As you go through your process, try to get good information about at least one of these areas at each step.
My favorite thing to do is, between in-person interviews, be able to tee up the next interviewer with "I got mixed signals about communication style. Can you dig in?" When you wrap up, make sure you cover all the boxes. Don't get smitten with a candidate with amazing experience who can code circles around everybody else who's never worked in a 25+ person team (assuming that's what you agreed was important). When you're ready to make a decision, you now have a reasonable set of trade-offs to make. I tend to create rubrics where solid scores in 3 of 5 categories is a Hire, to allow us to compare different types of candidates.
Ok, back to GitHub.
GitHub can give you VERY STRONG SIGNALS for some of these issues. It's great to be able to know up-front that somebody is comfortable working with teams they don't personally know well (typical in big open-source projects). The convese to that is that I generally expect some strong signal up front from any candidate. If not GitHub, give me a respected company on your resume. A recommendation from a mutual friend. A well-written cover letter. When folks complain about 100s of resumes, it's because the problem is this lack of signal.
An aside: it's on you to allow folks with non-traditional backgrounds to succeed at this step. Write a better job req, or go email likely candidates. Diversity requires multiple ways in. Once you're a bit further, this cuts the other way. If "good communication in pull requests" is important to you, don't spend any time here with candidates who have strong Githubs.
You already have all the data you need. Spend your time elsewhere. There is no extra credit. GitHub can help you a bunch when evaluating candidates, but it's crucial to stay away from this notion that _anything_ during an evaluation that looks like a silver bullet. You always have to do the work of interviewing well, and it's always specific to your company.
Finally: if you have a process that allows you to fully evaluate a candidate by reading their public GitHub, you're almost certainly hiring for the wrong things.
"Why Diverse Teams Are Smarter" - HBR [1]
"Diversity and Work Group Performance" - Stanford [2]
"New Research: Diversity + Inclusion = Better Decision Making At Work" - Forbes [3]
There's a drumbeat of this stuff, both old and new, that comes out constantly.
[1] https://hbr.org/2016/11/why-diverse-teams-are-smarter
[2] https://www.gsb.stanford.edu/insights/diversity-work-group-p...
[3] https://www.forbes.com/sites/eriklarson/2017/09/21/new-resea...
In particular, though, the only over-represented group is asians: 35% vs 5%.
- Sit on customer calls
- Read whatever approximates the "done recently" engineering tasks: git commits, Jira, sprint boards, whatever.
- Show up to meetings you weren't invited to.
- Take 6 different people out for coffee and ask them all the same 6 questions. Whatever you want to know.
- Sit on customer calls
- Set up the product and try to do something with it.
- Better yet, set up the product and try to do a thing a customer is trying to do.
- Did I mention sit on customer calls?
Once you know what people are working on today, it's easier to pick up and help them. Then you can start in on your own initiatives with credibility and support from the people you've helped.
- The pricing is $15 / user a month. This is a small purchase for businesses.
- The product is in a crowded market. Comparison shopping is the norm.
- The target is SMBs. Simplicity / ease-of-use is big for this market, vs larger businesses.
- The product is in a mature market. People have well-defined expectations of what this software should do.
- The audience is customer support, or perhaps generalists / founders.
- Testing the software in "production" is hard, because it requires you to answer support tickets through it. It may be impossible to get full value from this product without committing to a trial, which implies a certain amount of investment.
The conclusions in the post are highly dependent on the specifics of this product and market, so take them with a grain of salt. If you're making a better CI/CD tool, or a better analytics dashboard, you may find that an entirely different approach works for you.
10 500s in a row? Go to the timeout chair until you get better.
If you're trying to build an audience based on pithy advice in a well-known space, there are a lot of posts like this that apply. Focus your ideas, write about one thing, make it relatable, bold a couple random words, and Bam! Traffic!
If you're writing about something technical, complex, or sophisticated, it's worth spending more time to get it write. If you're writing for developers, include code and make sure it runs. If you're writing about hard topics, find research to back up your conclusions and build a real narrative (Priceonomics does this well).
Especially as a founder, your goal should be to write the definitive piece on whatever your topic is. As somebody starting a company on that topic, you are legitimately one of the foremost experts on this topic, so people want to hear your thoughts! Keep all those other rules in mind, buy don't sell yourself short by writing half-hearted pieces that sort of rehash the same topics.
For example, where I work, we think that traffic management (routing, proxies, service mesh, all that rot) is a better way to do things if you've gone to microservices. One example is releasing software. So we wrote one article on it (in two parts). It's long, it's technical, and it has been so, so successful. We don't try to reinvent the wheel on this topic. We just point people to this post.
https://blog.turbinelabs.io/deploy-not-equal-release-part-on...
Imagine a simple system where people are only evaluated for credit cards and mortgages, and businesses can only offer one of these services. Some people are systematically denied credit cards. Now they have to have more cash for daily needs, which makes them objectively worse as home owners, so the mortgage loaners pick up on this fact and start systematically denying them mortgages.
There's no business opportunity here. For either lender, the prospects in this group are worse, only because the other lenders think so. Breaking the barricade is much harder than just starting a new lender or either type.
There is a new world of their product, and even though it's 2018, they're not in it. It might feel like Spotify has won, Netflix has won, and so on, but in other verticals, subscriptions still aren't the norm.
Remember when Dollar Shave Club started selling razors by the month and got bought for a billion dollars? P&G needed to find a way to transition to subscriptions, and they paid up for it.
The subscription economy is a real trend, and it's not something you can just convert to overnight if you have a business that's a going concern. You have to figure out how to put out some new offerings, and the way people pay for these new subscriptions have to work with your existing business processes.
Zuora sells to those companies. Companies that want to sell subscriptions, but can't throw the baby out with the bathwater. They want to work with a company that understands that subscriptions are the new important thing, but not the only thing.
My favorite part is that 25% of their revenue is professional services, and their professional services are sold essentially at-cost. You're going to need somebody to help you get set up, but at least the pricing on that extra headcount is fair :)
They're after large customers, and this is what they get.
"As a substantial portion of our sales efforts are increasingly targeted at large enterprise customers, our sales cycle may become increasingly lengthy and more expensive, we may encounter still greater pricing pressure and deployment and customization challenges, and we may have to delay revenue recognition for more complicated transactions, all of which could adversely impact our business and operating results."
Trade shows, performance marketing, affiliates, content marketing, retargeting, account-based ads ... those all work well.
At the time, that was nginx + manual autoscaling, then it was ELBs and autoscaling groups, now it's kubernetes and containers, maybe hosted. It's still not there.
I'm excited about the software that makes that operable at scale. It seems like a service mesh is a good idea. It seems like mutual security between services is a good idea. It seems like storing routing configuration in a separate control plane that is executed in a data plane like Envoy is a good idea.
There's a bag of software at CNCF that's loosely organized around this, but I don't think the "just deploy some code, it can scale and you can have tons of services doing that with good visibility and operability" is quite there. I'm really exicted about Envoy, but I don't think there's a good control plane for it. I'm part of a company that's working on a commercial implementation (turbinelabs.io), and Istio is in a similar space.
There's still work to be done!
The domain I'm specifically thinking of is managing routing rules, like nginx configs or control-plane configs for Envoy. It's really tempting to simplify it down to a config file, then you version-control it, then you get merge conflicts, and all of a sudden a bad merge makes 10% of your services unroutable. Which is hilariously bad.
Having an auto-merge for those sort of configs seems like the only reasonable way to do it. Escalating conflicts up, from easy merge, to trying an automatic strategy, to surfacing conflicts to the user in a domain-specific way, seems like the only way to do it!
Five weeks of, say, three engineers with $150k salaries ($200k fully loaded) is $60k. People say that the majority of software is after initial development. Let's say 20% is development [0]. That means this project costs $300k total and lives for 5 years before the team decides to rewrite it. That brings us to $60k / year.
This is good savings! My general guidance to folks thinking about this sort of project is that you should implement a vendor and see how you like it. The reason being, MixPanel does a LOT more than this tool, and buying a vendor can help you figure out the subset of features that you actually need. Once you have a clear requirement list, you have a clearly scoped project and can hammer it out relatively easily to get that cost savings.
Beware of thinking that you can do this for $X,000 / year on your own, or get it right on the first shot. There's a reason MixPanel (and any other vendor) has so many engineers. You're paying them to have already made the mistakes that you're about to make.
[0] https://stackoverflow.com/questions/3477706/development-cost...
One of the main markers of a startup is there tends to be One Big Challenge to get the company to The Next Level (generally talked about as a funding round, but that's just a convenience). Initially you're finding product / market fit, then you're figuring out a scalable go-to-market, then you're scaling the product, then you're launching a new product, etc.
It's weird to go through one of these transitions, because you'll need to change your focus pretty drastically. Sometimes you'll feel sidelined, because your department isn't the one primarily on the hook. If you're figuring out how to build a sales team, engineering gets chill and potentially complacent. The most successful startups have leaders that paint a clear picture that gets all departments working autonomously towards the same goal.
This is different than a smallco, because without a war chest of cash, your options are more limited. Because cash flow dictates the cadence of the business, and that's never going to change. This can feel more stable, but does mean you'll have to occasionally make hard choices that delay a valuable project or work on something outside your speciality.
Here's a counterpoint: https://twitter.com/aphyr
I can't speak for all the harassment he may or may not have endured, but it's not on the same level as Wu. He makes fun of his weird pairing of interests in his featured photo. He doesn't have the CEO of a company and de facto leader of his professional association questioning his competence on Twitter. Whatever he's dealt with, it probably hasn't been "this is so offputting that I'm going to question the fact that you even exist."
Honestly, I had the same reaction as you. I don't think it's OK to question people like Naomi in this way, because I'm pretty sure I'm doing it unevenly. It's something I'm trying to figure out if I do elsewhere, and how to improve. This stuff is hard.
The salient bit:
> A quick note to everybody who says 'calculate the hash locally':
> A) Photo fingerprinting algorithms are usually not included in clients to prevent the development of circumvention techniques.
> B) Humans need to review to prevent adversarial reporting.
Further down the thread, they discuss further that PhotoDNA and similar algorithms are, in particular, not resistant to being tricked. Until they are, it's another layer to prevent adversaries from fully decomposing how they're hashing it, which is a good thing.
It's a trade-off, for sure, but this is a hard problem with no cut and dry answer. Facebook already has the images in question, because you have to be sending them to somebody in order to mark them as NCII. Asking yet another Facebook service to look at them without storing them seems reasonable to me. You may disagree.