This is one of the dark sides to having an entire engineering team in the 25-30 age range. They can sling http just fine, but sometimes don't fully grasp the consequences of their work.
It's more about heavily interviewing for alignment with your mission. If people care deeply about the problem you're solving — not just the technical problem, the people problem — then you're far less likely to have these issues.
I interviewed dozens if not hundreds of people at ZP and there were two red flags for engineers:
1) They only care about the technical problems. In this case, they're likely to make decisions more aligned with "that's interesting" than "that helps our customers"
2) Once we raised our Series A, we had a lot of applicants wanting to join a rocket ship. I literally heard that in an interview with a Facebook engineer who found us by "googling startups with 9 figure valuations." If you care about growth at all costs, you're going to cut corners and fuck over your customer.
Mission matters. Values matter. Interview for them.
His view, if I'm recalling correctly, was that hypergrowth makes customer problems more visible due to scale while making the company inherently more valuable. There was absolutely no downside to growing as fast as your imagination could manage - despite an accumulation of red flags, technical debt, and unhappy employees.
As you mentioned in your comment, values absolutely matter. I think Sacks gets this, but a company this deep in with so many employees is a big, unwieldy ship that's hard to turn.
I worked at LivingSocial early in my career and this is so true. There is a limit to how quickly organizations can grow (given our current understanding) and still be healthy.
Employee happiness and related metrics (e.g. retention) is the biggest indicator of health. I don't care that you hired 400 people this year. Can you retain 40 world-class people?
It is absolutely more rare to find younger people who are already aligned with that mentality. That's not good or bad, just a matter of fit.
So hacking is reserved for research project and the odd on-off script which gets nowhere further than my PC ;)
I've had hackers in my team, they've always been strong technically (they take risks so learn fast) but they have always been a net negative in the long run if left uncontrolled. But put them into the right environment and they can be very effective (as they tend to be very creative).
The question is will an ex-Facebook hacker accept being kept at arms-length production and treated like a junior developer? It works for me because there aren't any AAA employers here in The Netherlands.
Their recent series A made them so cavalier; they landed money to do this, so of course it was right. It would eat into profits if they negotiated contracts to do it aboveboard.
https://twitter.com/williamalden/status/697898496314077185
<<I’m told that Conrad created this program based on a belief that 52 hours was too long to spend in training>>
The LMS has the actual license exam locked until you've clocked 52 hours inside of it, so the macro just ran out that timer until the broker could get directly to the exam. Scraping by an 80% on that license exam (especially with all of your colleagues around that have taken it already) is ridiculously easy.
Insurance companies are sticklers for technicalities and love to deny claims, so as a consumer I'd consider the 52 hours / 6.5 work days worth of required training to be an absolute necessity for an insurance broker.
Disclaimer: My current company got our insurance royally screwed up in the short period of time we used Zenefits thanks to their corner cutting, so I'm a bit jaded.
You don't have to be old to build things safely. You just have to care.
I recall that when Parker Conrad spoke at the Stanford startup class, he said that he'd been turned down by many VCs, at least one of which said "Well, if you were Twitter, this would be a different conversation." His take-away from that is "Well then, what can I do to become Twitter?" Only problem is that health insurance and 140-character text messages are wildly different industries.
In other words, when I picked MongoDB to store NowPublic SCAN data, before the word NoSQL was in vogue, even, then it was scanning various streams (including the Twitter gardenhose so many years ago) for bits of news and the ability to store lots and lots of small bits of text quick as hell was much more important than keeping all of them. Noone really cared about every single one, we were in the business of surfacing breaking news and we were a very small startup so not needing lots of expensive servers were a huge plus.
Obviously I picked a very different data storage model when I needed to store payment data at a TV station's video store...
We used Facebook as an example all the time. For them, moving fast and breaking things is a good value. If someone's status update got lost, that isn't ideal, but it isn't the end of the world.
When people don't get paid, that's a Big F-ing Deal.
It's an easy trap to fall into as an engineer. There are many cool problems to solve, but when you join a team you're agreeing to solve their problems. Focus on the customer.
The Valley has started to equate "disruption" with breaking the law. This is its natural consequence.
Code is not written in a vacuum. The hardest part, for three nines of software problems, is not just getting it to work. It's architecture and building an engineering team that functions together. People are a major component of software development.