Leading failure
Leading failure
Another excerpt the book I’m currently working on - check out the full draft.
You’ve likely heard of another Google tool, blameless post mortems which encourage people to go over large failures with the goal is to both explain how they fixed the problems, but also to encourage and, even “celebrate” risk taking.
If you’re switching to a product-driven approach to software and business design, you’re asking staff to be innovative, to learn new ways to do software and run the business. And this is just for product teams: think of how much we’re asking finance to change!
Being innovative requires taking risks. We’re always going on about how much we value “risk taking,” but usually what we value is “success.” Taking risks though usually results in more failure than success - otherwise, it wasn’t much of a risk. That “failure,” though, is a positive asset: it means you’ve learned something that doesn’t work and can move on to finding something that does. It means you’ve at least tried, which is much more than your sleepy competitors will do.
You’ve got to make failing acceptable in your organization, otherwise nothing will happen. Many organization who do so have what they commonly call Fuck Up Fests, a phrase I’ve heard many times in many organizations so I’ll risk making you blush by using that word. These happen, quarterly or twice a year and demonstrate that leadership is serious about supporting risk takers. And, it’s a good way to drive camaraderie and learning, all helping create psychological safety and that curiosity we’re looking to marble the culture with.
That all sounds peachy, doesn’t it? Come over to the circle and sit criss-cross-apple-sauce and here Gene tell us about the time they brought down production for thirty seconds and cost the company $10m. When you ask your staff to embrace failure-as-learning, none of them are going to believe it. They won’t volunteer to celebrate failure and learning in public, let alone at the company wide meetings that Google is said to use. Instead, you’ll have to lead by example - fail by example. Find ways to talk about how you, senior leadership, has failed and how the company was better for it. Or, just how you failed.
You and other leaders will likely need to fill the first few slots of your fuck up fests before you find someone brave enough to share their own fuck-ups. Once you do get more and more people sharing their failures, you’ll know you’re moving your culture in the right direction.
Original programming
On this week’s Software Defined Talk episode: Kubecon and Slack vs. Microsoft Teams. Plus an Oracle cloud press release NOT TO BE MISSED.
Also, burritos in Amsterdam.
How to enterprise infrastructure software market
Somewhere on my list of books to write is a paste-pot book on marketing, marketing infrastructure software (operations stuff, cloud, developers, and the stuff a business would do with it).
Brandon and I did a series of podcast discussions on this topic, and I’m thinking I could start with transcripts of those.
We called it the Software Defined Talk Members Only White Paper Exegesis podcast because it was originally behind a Patreon paywall - but now it’s free in the Software Defined Interviews back-catalog.
Here’s some chapters I’ve been thinking of:
- Finding the strategy, sales motion.
- The funnel and renewal.
- Press releases.
- Analysts.
- Blogging.
- Podcasting
- Whitepapers and O’Reilly branded books.
- Conferences, meetups, etc.
- Executive dinners.
- Managing inward.
- Presentations.
- Understanding the product and telling a story with through customer stories.
- Customer profiles.
- Developer relations.
- Listing pricing for doing this (inc. hiring agencies, typical salaries, conferences, events, etc.) would be good.
Modernization, legacy, tech debt
For the most part, my job is talk with executives about transforming how their organization does software…and doing the research so I have something to talk about.
One of the top three topics is dealing with all that existing, legacy IT out there. Modernization.
I’m moderating a webinar with one of our customers, AirFrance KLM about just that topic, how they’re tackling 2,000 “legacy” applications:
Like all large companies, AirFrance-KLM has a powerful software portfolio running its daily business. A couple of years back, the company identified over 2,000 of these applications that would benefit from being modernized. Putting together a strategy to do this over the coming years is, understandably, a large undertaking.
AirFrance-KLM had to choose which applications to modernize, but to do this they first needed to build a model to select applications and then actually do the migration. They also needed to select the platform and development methods to get started.
Tune into this webinar to hear how the team at AirFrance-KLM achieved savings, speed, and resiliency, and the lessons they learned along the way.
It’s December 11th, so check it out if that’s something you’re facing - chances are, it’s high on your list of shit to deal with (modernization, hopefully, not, this webinar).
There’ll be a recording too, so register even if you can’t attend live and you’ll get that emailed to you (I think).
Relevant to your interests
The writing in this essay is amazing. “You’re invested in the status quo, since it put you there. You’re the Marxist conception of the bourgeoisie.” Information design graphic arts charts and stuff awards. “So many people confuse innovation with change.”. Tech debt: “[m]uch of this IT work requires unwinding our legacy systems, and that has proven to be more complex than originally anticipated.”. Connecting stuff up with APIs at AFKLM. You’d need a whole, separate bag to carry all this stuff. People tend to use older versions of Kubernetes. “Cheif Purpose Officer.” The Halo Effect, but first mental shit: “[a]ll therapy books start with a claim that their form of therapy will change everything.”