Rick Rubin’s Podcast

I like Tetragrammaton podcast a lot. (It’s one of those big deal podcasts that doesn’t actually have it’s own home page, which is totally weird - just search for it in your podcast listener or YouTube).

Why? One, it is luxuriously long, Rick Rubin really gets everything out of the guests. Two, he asks great questions: at first they seem naive and simple, but then you hear the answers and stories and you realize how great the questions are. Coming up with and asking questions that get great answers is very difficult.

I think most of his questions are either asking “how?” as in “how do you choose an album cover?” or “how do decide if a joke is good?” His other frequent question is “what was that like?”: he likes asking people in advertising or adjacent industries “was it really like Mad Men?”

If you’ve seen that meme that’s like “how a person looks at a bookshelf” versus “how a carpenter/artist” looks at a bookshelf," he’s always doing the second.

He’s just so chill too.

He very rarely has anything negative to say. You leave each episode pretty much feeling great and optimistic.

As an exception that proves the rule: in one interview you hear him almost putting down executive types at record companies who are more interested in selling than creating good content. He says, they don’t know what they’re doing. But that’s about as far as the negative vibes goes.

Some of the episodes are a little weird if the people he’s interviewing don’t have much to say. I skipped over some two part series of, you know, magic powder doctors early on.

The content is good, and long-term there’s some kind of world-building going on that’s attractive. He’s building a world of curiosity, creativity (even “art”), all bound up in a world-view of just chilling the fuck out.

I mean, he’s rich and famous. We’re hearing from the rare exception to the thousands of producers and creative types that didn’t make it big. But, if you can put aside the accurate but boring Halo Effect criticism, it’s good stuff.

Also: the ads he has are fun to listen to and many of them are super-weird (nutrition-scammy) products. Macadamia nuts? Powdered imitation-gatorade? But, the actual ad reads and production are fun!

Wastebook

• We’ve passed a fuck-line here in Europe. I’ve seen the word “fuck” on more surfaces than ever: t-shirts, for sure, laptop stickers, on cars. I feel like it’s still spicy talk in the States, but overhear it feels like part of the general European trend to just like, well, not give a fuck.

• “Clarity first, then consistency.” Here.

• Three groups of people were playing cards in the Zadar airport. Is that a Croatian thing? Who ever plays cards anymore?

• “The Church of Recurring Revenue.” Here.

Have you tried just following best practices?

Don’t let the factory rust.

• Why and how cloud native technologies give you more control over your software delivery process? A rough answer: Cloud native apps are modular, container-based designs. They run in container orchestration engines and, it is hoped, have much of the infrastructure and networking stuff automated (though, this is yet to be fully realized and creates a problem in its own). Assuming the happy path: they're designed to be efficient to run, fast to deploy, and decoupled. This means you get more cost controls and more agility. What's important, though, is to standardize on how you do this.

• Much of what you probably suffer from now is having to deal with a whole bunch of different ways of developing, managing, and running applications, tech debt, and having to spend time manually doing compliance and security checks. "The business" and developers don't have enough cycles to study what users actually need, experiment with the best way to solve it, all while making sure they comply to internal standards and regulations. Doing all that "not the actual UI" work (moving pixels on the screen!) takes a lot more time than you ever think. One person in banking estimated that amount of toil at 50% to 60% of their team's time.

• Before we get to any of that, though, you need to make sure you’re thinking of software as a core part of how your organization runs. Here’s a simple test: who decides what your developers do? Are they given requirements and “wire frames” from another group and given a date to hit? This probably means you’re doing it wrong. Are they told what you need to accomplish and why those goals are important for “the business,” and then they can decide how to deliver those “outcomes”? You’re probably closer to good software culture.

• No matter what tools you use, if you follow a command-and-control approach to software, your results will be less than ideal. People know this is lean manufacturing: you push the work closest to the people actually doing the work. It’s no different in software, and, in fact, is even more so. With software the developers and operations staff are both working on the line and building the factory at the same time. They should be the ones determining what to do.

• Eventually management can take a bigger role as they become more like developers, or understand how software works. In tech companies, many of the founders and executives are (former) developers, so they of course know how to manage and get results from developers and operations people. Is that the case in your organization? What is management’s background? The board?

Relative to your interests

• A new way of thinking about open source sustainability - If you’re using open source components in your IT stack, don’t forget that long term reliability and stability is costly, and worth paying for.

• “We gave a profession of bullshit generators access to GPT-4. You won’t believe what happened next.” - If the work you’re doing is predictable - in this case, a lot of the junior level work at management consulting firms to come up with new strategies and GTM - the AI can help. The positive side: if you’re considering getting the consulting firms to bootstrap your annual planning, try a week with ChatGPT instead and see if it feels the same. Then don’t hire them, as much? Also, the AI is good at hype-marketing.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Oct 3rd Enterprise DevOps Techcon, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Oct 10th, 17th, 24th talk series: Building a Path to Production: A Guide for Managers and Leaders in Platform Engineering Oct 12th Spring Tour London Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

I have a week and half before I travel again (see above) - and then it’s a doom-doozy of a travel week, plus more travel to follow. And, as you know, outside of the talk you’re giving or the meeting you’re having, very little gets done during work-travel. There’s also a series of three webinars in the works. And, I need to create/learn a new talk or two during that time. Meanwhile, there’s other macro-winds on the horizon way above my pay grade.

It almost seems all undoable! I wonder if that’s why I’ve been feeling more anxious than usual of late…

I’ve been thinking a lot about one of my annoyances working with experts/practitioners (well, anyone) over the years: they’re always telling me they don’t have time to take on new work, their backlog is full. And, I’m like, “I just want to record a podcast!” Turns out, you can just say no. Is that a way people work? Could I just say “oh, I have travel upcoming, a three webinar series, and then I need to make at least a podcast a week, and can you imagine how long it took me to type up that rant on analyst reports (a lot shorter than you think because I basically took one pass and didn’t edit it - but you get what I’m saying), so I can’t do that podcast”? Would my life and bank account be better? Would my work be better? Would my employers finances be better? At a startup…no? But at a regular company?

There’s something to be said for calibrating on “only work on things that matter, that have impact.” Which, I guess. But I also feel that in a big company, you hire a lot of people to do work on the mid-tier “impact.” The management/work advice we all soak in from startups and “high growth” companies seems hardly applicable to, like, the real world.

I have no calibration for those things. It’d be nice to have some, though.

(Also, I just ordered an iPad mini - I didn’t realize they had that size with the Apple Pencil. I love using my big ass iPad Pro with the Apple Pencil, but I rarely do it. Could this mini get me over that edge. In theory, it’s also the perfect form factor for Kindle books and even PDFs [I think you’d have to landscape the iPad mini and scroll through the PDF instead of going full page, but that’s probably fine]. My main concern is, like, protecting the pencil. I need to find some kind of tape on hard-case that I can have for when I want to do the whole throw the iPad in my bag things. However, the main scenario I’m targeting is a go-bag with my video recording gear [tripod and iPhone mount with hot-shoe, Rode Wireless II’s, various cords] and the iPad mini. Throw in a little foldable bluetooth keyboard, and this feels like a good setup for trips where I can leave my laptop behind. The only thing I really need a laptop for is editing slides, probably? I think you can record podcasts and even present from iPhones and iPads. THE DREAM.)

The premise of this book, for most anyone, is painfully boring: planning out and project managing the installation of COTS software. This is mostly lumbering, on-premises ERP applications: those huge, multi-year installs of software that run the back office and systems of record for organizations. While this market is huge, touches almost every company, and has software that is directly or indirectly touched by almost everyone each day (anytime you buy something or interact with a company)…it’s no iPhone.

If you’re in the business of selling enterprise software and services, however, Beaubouef’s book is a rare look inside the buyer’s mind and their resulting work-streams when they’re dealing with big ol' enterprise IT. As a software marketer, I read it for exactly that. I was hoping to find some ROI models (a scourge of my research). It doesn’t really cover that at all, which is fine.

There’s a core cycle of ideas and advice flitting in and bout of the book that I like:

1. COTS software will do, you know, 80% of what you like. The rest is customizing it through configuration, your own code layered on-top, or getting the vendor to add in new features.
2. The more you customize the software, the harder it will be to change. But, the less you customize it, the less it creates differentiation for your business processes.
3. Most of the problems and challenges you’ll encounter, though, will be human-based.
4. Much of these human problems are about managing the requirements process to make sure the software is matching the needs of the business.
5. Process-wise, to do this we like to take on a waterfall approach (try to specify everything up front, implement it all, then verify if it works). This results in a lot or risk of waiting for that final verification to see if it works and you were right about matching the COTS implementation to business needs.
6. Instead, an iterative approach that focuses on learning and honing the COTS/business match-up seems like a good idea.
7. Role-wise, getting someone(s) who has a tops-down view of the business process and enough technical understanding to map that to the COTS project is a really good idea, though hard to put in place.

While the book focuses on on-premises software, the overall thinking could easily apply to any implementation of a large IT-driven, vendor provided system: SaaS would work, and to an extent the kind of infrastructure software we sell at Pivotal. As the points above go over, the core thrust of the book is about managing how you make sure your IT is actually helping the business, not bogging down in its self.

If you’re pretty vague on what you should do in these large IT initiatives, you could do a lot worse than read this book.

Check out the book: Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations