ClusterHQ is shutting down

I read the whole book, let me put Catmull's quotes in context. They're not really generalized startup/life advice; Creativity Inc. is targeted toward people who are already in management and want to improve their department's output.

While the root principle that failure is a mile marker, not a road block, on the path to innovation can be extracted, Catmull's book itself is not really about that topic. Rather, it's about how Pixar came to be (recounting major events in company history up to publication, including the spinoff from LucasArts and the death of Steve Jobs), the principles that power Pixar's culture, and how Pixar seeks to instill those principles in its employees.

In context, I feel that Catmull is specifically addressing two points when he discusses failure. First, dealing with failure within the ranks of your workforce and second, imbuing upon the workforce a confidence that allows them to be mutually critical without getting hostile.

Catmull is a engineer first and foremost, that's what needs to be understood going in. He is taking an engineering approach and applying it to management. IMO, Pixar is an excellent example of what happens when one does that.

The first point about not firing people over mistakes or bugs is something that engineers know well, but non-technical people may not understand. A bug, a hole, a mistake, a vulnerability, a typo (like the one that almost deleted Toy Story 2 and could've destroyed Pixar if not for an accidental backup on the home computer of a telecommuting employee) is not a valid firing offense. You need to hire smart people and give them room. That includes acknowledging their humanity, and that the best of us are still going to make simple mistakes sometimes, just because we're human. Even elite runners trip and fall sometimes; practice doesn't make perfect but it makes very good.

Dismissing good talent based on the types of simple mistakes that are essentially random events is first, very wasteful of both monetary and talent resources, and second, antithetical to a culture that teaches that mistakes, experimentation, learning, and exploration are not only OK, but necessary parts of doing things that are worthwhile.

The second point is more about the employees and developing a culture where they can be comfortable that their image and reputation is not impugned when a colleague expresses his or her honest beliefs about their work product, and vice versa. This is another thing that engineers really value and understand well, but which causes a lot of non-technical people to worry endlessly.

Catmull recounts how many people need time to adjust to a culture of free, open, and fair criticism (which makes sense, as many corporate ranks are terrorized by glancing, unstable egomaniacs scattered throughout the ladder) and how Pixar assists them in developing the mutual understanding, trust, and respect that allows them to provide true and honest feedback to one another without becoming bitter. That is, "failure" in one task is a lesson to be learned from, not a fault to be feared, and such "failures" are welcome at Pixar because they understand it is an intrinsic element of exploration and development. Pixar's task is to help its employees internalize these values, so that such open criticism can refine their output into the exceptional pieces of art that they're known for producing.

Pixar, via Catmull, is a wonderful example of what happens when a smart, fair, and directly involved leader is allowed to control something he knows well. That's something that happens all too rarely. We'd have many more Pixars if we could get more Catmull-esque people in positions where they could override the drones who go around flashing their MBAs.

Yeah, I'm really looking forward to a true local storage option. I'd recommend watching https://github.com/kubernetes/kubernetes/issues/7562 and https://github.com/kubernetes/kubernetes/pull/30044 if you want to keep up with how things develop.

It's a bit unfair to make absolute statements like that.

As with everything else, there's a risk calculation involved. If the PaaS/SaaS company delivers a substantial improvement over the existing solutions, the risk may very well be worth it. Conversely, if you're replacing a tried-and-true solution with something shiny just because it happens to have a lot of buzz around it, well that can be a risk miscalculation. (Of course, the shiny new thing may be worthwhile because it attracts a certain class of talent, but shiny for the sake of shiny is not going to yield much good.)

That's why larger clients sometimes invest in a startup, to help ensure some stability by having better access to the internals. (Yet, I've seen that fail too: some startups outright lie to their investors, and that ends just the same way as you'd expect.)

I agree that persistence in k8s is tricky, especially at scale, but at least in our case that doesn't drive us way from the platform. Kube is awesome for services, and if we have to keep a few things on gcloud instances bolted to reliable storage for the moment that's at least less heterogeneous than what we had before kube came along. In other words I don't think you have to kube all the things to see a lot of benefit.

Why would it take you 3-4x longer to launch? Running your own servers in the cloud is not that hard. You can actually save time by not being restricted by the PaaS. I.e. if you have special needs, and you will, you can go in and hack the software.