This is about spread of innovation. He talks about anesthesia and antisepsis, but you can easily see parallels to technology. He talks about understanding existing norms and barriers to change and how neither incentives nor penalties really work. Very interesting. I’ve been thinking a lot recently about how to best institute change in the organization and why certain teams fail, even though they produce great products from an engineering perspective. This offers some insight into that. If you’re attacking a big, but a mostly invisible problem, it is very hard to get other people bought in.
I was reading the latest Paul Graham essay: “Do Things That Don’t Scale” and it got me thinking about devops, infrastructure automation and why “tools” teams fail. I am sure I am suffering through a bit of a confirmation bias here, but this article can easily be applied to a team or a culture within a company. If you see yourself as a startup, you have to think who are going to be the users/customers/stakeholders of your product and what you need to do to delight them. That’s a path to success.
The quote that jumped out to me the most was this:
If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users’ problems in a way that wasn’t yet automatic, but less frightening than the far more common case of having something automatic that doesn’t yet solve anyone’s problems.
I think that ties right back into the devops philosophy of people over process over tools and why a simple “automate all the things” approach is sometimes not enough.