There’s a creeping notion that Claude Code (and OpenAI Codex, I guess) are very useful for things that are not code. In the Obsidian community, where you keep your decades of notes as plain text, markdown files, some people are using Claude Code to do analysis, reformatting, etc. of their notes. I can see that you could do the same thing with the pile of Dungeons & Dragons stuff I have laying around.

This makes sense, really. Source code is just plain text as well.

Doing this kind of thing from your desktop, where you control all of the integrations and data access instead of waiting for a developer to do it for you, feels like it’d be easy. I think the Goose people are figuring out this form-factor for AI apps: focus on building out a tool belt (MCP as plugins) for a general purpose chat app rather than fit-for-purpose apps that use AI in the background. A classic suite versus point-solution situation.

Here is my current theory: the GenAI we start seeing in enterprises won’t be integrated into your existing apps (like online banking), but will show up (still) in the form-factor of chat apps in those apps (those little pop-ups in the lower-right hand corner, except now they have all your context) or tool belt apps like Goose.

That is, AI will not be integrated into existing apps, it will be a new, stand-alone app (or “workload”).

Somewhat related: I’ve been consistently disappointed by Gemini’s integration into Google Suites (we have this at work). Yesterday I asked it to do some simple reformatting of a column in Sheets (convert date formats) and it flat out said “I can’t do that.” I took a screenshot of the dates column, gave it to ChatGPT, and asked it to reformat the dates and output it in a format ready to paste into Sheets. It did it perfectly, instantly. Most of the time when I use AI integrated into an app, I really just what the standard chat interface that can pull from and push back to that app.

That feels like what Claide Code is trying to do. I’ll have to try it out in Claide Not Code style.

The new Use Model shortcut in Apple Shortcuts opens up a lot of possibilities. For example, I like to summarize a lot of pages. Sometimes, ChatGPT can’t get the text for those pages, or I don’t trust the text it retrieves. There’s a shortcut that will retrieve the cleaned up text of a page (as markdown). So, you can get that markdown, and with the new Use Model shortcut, you can summarize it and then send the markdown summary to Drafts. You could open the text up in another app to view, whatever you like, but as you can imagine, I like to catalog this stuff. Also, it can generate a little link to include for my newsletters link list.

You put this in your Sharesheet, and now when you’re reading the World Wide Web, you can get summaries real quick-like.

Here is the shortcut:

I left in the stop and output for debugging, but I’d take that out.

Here is output from one of my articles:

Developers Aren’t Using Your Platform? Marketing Might Be the Missing Link

Source summarized: Driving Platform Adoption: The Missed Opportunity of Marketing.

Internal Developer Platforms (IDPs) often fail to gain traction despite delivering exactly what engineers request. This piece argues that platform marketing—alongside product management and community building—is the missing discipline most teams ignore, and offers a systematic approach to drive developer adoption.

Key Insights

• Define your developer audience narrowly before pushing adoption efforts.
• Craft messaging that focuses on developer benefits, not platform features.
• Position your platform in clear, specific contexts (cloud-native apps, AI workloads, regulated environments).
• Lead with value propositions that are measurable, like time savings and frictionless onboarding.
• Avoid the “platform for everything” trap; targeted positioning accelerates adoption.
• Integrate marketing with product management for tighter feedback loops.
• Use developer-friendly proof points (fast deployments, pre-approved services, reduced ticketing).
• Iterate adoption starting with a few archetypical teams before scaling org-wide.

Most organizations spend years building internal platforms that meet developers’ stated needs, only to watch usage stagnate. Teams often assume technical excellence alone will win hearts and minds. The authors note that marketing—treated as a rigorous engineering-like discipline—can bridge that gap by creating awareness, clarity, and trust. The first step is laser-focusing on the actual developer persona who will use the platform. “Developers” is too broad; target application developers in specific business domains and technology stacks to avoid generic messaging.

Messaging, positioning, and value propositions form the backbone of platform marketing. Messaging should translate features into developer-relevant benefits: zero setup time, fewer meetings, and faster deployments. Positioning narrows the platform’s role in the ecosystem—rather than claiming to be universal, identify where the platform delivers the most leverage, from legacy modernization to AI-driven applications. Value propositions then provide concrete, provable outcomes, like cutting deployment cycles from days to minutes or eliminating 80% of security review meetings.

Finally, the authors emphasize that platform marketing is not fluff—it’s how you engineer adoption as deliberately as you design pipelines. By starting small, learning from early adopter teams, and communicating benefits in precise, outcome-driven language, organizations can finally capture the ROI on their internal platform investments. Marketing is not a side hustle; it’s the connective tissue that transforms a platform from shelfware into a strategic asset.

• 🤖Driving Platform Adoption: The Missed Opportunity of Marketing – Explores why technically excellent internal developer platforms still fail and how adopting structured, developer-focused marketing can dramatically improve adoption.

Summarized by ChatGPT on Sep 16, 2025 at 1:09 PM.

Fantastic! I used to have to do this manually.

And, are the summaries good? They’re not always perfect, but I’m often looking to see if I should spend the time to read the whole thing, especially if it’s long and…not the best of writing.

There are many things I like, but these are some I can think of now¹:

1. Above all else, I like making content and publishing it.
2. I like reading short things (I used to like books, but now that I know a lot of the 101 stuff after ~40 years, I get frustrated/bored by how long it takes to get the good stuff/the point. I know the context, I want the fix.)
3. I like eating; I like drinking; I like cooking.
4. I like browsing markets and shops, but I’m indifferent to buying and possessing what they’re selling.
5. I like all museums.
6. I like to ride my bicycle.
7. I like being in flow.
8. I like friends telling me interesting stories, just talking to me.
9. I like flâneuring, but only in dense, chaotic cities.
10. I like traveling.
11. I like airports and hotels.
12. I like driving.
13. I like whatever Anatomy of Norbiton is; A Short Life in a Strange World is one of the only books I’ve read three times; Joan Didion; Hunter Thompson; Chuck Klosterman; Susan Sontag’s diaries (she has to remind herself to take showers more - YES!); Bruce Sterling lectures (his 2024 SXSW talk relating Leatherman multi-tools to…everything?…is representative) and wastebooking; I like people who use and then build up small, boring observations to try to figure out what the is going on woth everyday life (recently, taylor.town and Noah Kalina). That is:
14. I like people who are just as confused about “real life” as me and document their IRL safaris.
15. I like Tex-Mex. I like Texas BBQ. I like Texas food.
16. I like the idea of learning new languages.
17. I like the English language as she is spoken.
18. I like structured day-dreaming (e.g., solo-roleplaying D&D).
19. I like complaining about bad strategy (but I wish I didn’t).
20. I like coffee.
21. I like money. More-so: being able to buy whatever I want, when I want, like:
22. I like Apple products.
23. I like music.

Publishing Versus Orchestrating

You can focus on short term delivery, or long term delivery. Do you follow the Twitter drama day-to-day, or just wait every week or two to see what happened? Do you write an article in a day or two, or write a 40 page PDF in a month, 120+ page book in a year.

My brain is wired to find the pay-off in every moment, and to be present and remembering. Long term projects seem like I’m not doing work - all that time just…working, not publishing. It was blogging that did this to me, not Twitter.

(Here, when I say “publish,” I mean deliver something.)

Managers are rarely publishing/delivery frequently. Instead the orchestrate other people dong it: build the systems that everyone works in (the organization and “culture”), make sure there’s capable people in the system (hiring, retaining, career management), give editorial direction (strategy, goals), and check on the status of things (verify that things are happening, fix problems).

When I think about that work it seems like it’d be so unsatisfying: you’re never directly publishing anything! I know people who manage take great satisfaction in…making things happen, helping people, all that. And, of course, you often make more money, which is always nice.

Individual contributors (as they call people like me) often run around saying “we should do this and that…” or the unkind among us “why aren’t we doing such and such - what do all these people do?” That, perhaps, is a portal into orchestrating other people delivering: when you have that thought, rather than take that work on your self (which leads to you doing less overall because you now have too much work to do), why not orchestrate someone else doing it?

Some commentary on a recent survey commissioned from my work, VMware.

Unsurprisingly, open source is used by almost everyone. When it comes to what I care about software development, open source is indispensable. In fact, it’s hard to imagine a developer who only uses closed source software, if not whole systems like kubernetes or Cloud Foundry for running their applications. It’d almost be impossible. 

And, indeed, in our State of the Software Supply Chain survey this year, 2022, 90% of respondents said they were using open source in production.

Still, I wonder what those other 10% are doing! 

Do they write all their own software? They’re not running Linux in production I guess, either. 

What’s holding those 10% back?

• 44% selected we’re still figuring out how to manage OSS in production. 
• 38% chose we don’t see sufficient support for open source software in production environments
• 34% chose we don’t trust open source software for production environments.

Benefits

There’s so much they’re missing out on. For all this praise about open source for me, what are the benefits of using open source? 

80% of people said reduced costs. Now, a lot of people will tell you that open source isn’t free. What they mean is that the cost of labor to use and maintaining it (upgrading and security patching) in staff time and pay…but clearly people are benefiting from open source overall being cheap. And, of course, many companies pay for commercial support and closed source tools for the open source stuff they use.

Cost was also the number one benefit in our 2021 survey. 

The other benefits were flexibility, support from a large community, and developer productivity. 

All of these are the promises of open source and what we’ve come to expect over the decades. Indeed, if you look the reasons people chose open source and then the benefits they got, those expectations pretty much line up. For example, 50% of people said they expected developer productivity as a benefit, and 52% got that benefit.

Problems: Security

Let’s look at the concerns people have. 

Security is what we should really dig into since it’s such a big concern. Now, I don’t think the concerns about security mean that open source is NOT secure. I don’t really think that’s the case at all. I think open source tends to be as secure as any other type of software, closed or run in the public cloud. What’s important is that you have the right process, packaging, and management in place. Again, this is important for anytime of software. Open source software is as secure, or, if you like, as insecure as closed source software. Make sure to get the right tools in place.

I want to add my own criteria for using open source that you should consider: make sure there’s a thriving, well supported community that you can depend on for the long-term. There’s two reasons for this: you want to make sure you’ll get community-based support when you’re learning how to use the OSS and troubleshoot it. Also, you want to make sure over the years that new, innovative features are added.

A thriving community will address these criteria.

Packaging and management

What you want to do is make sure that community and the vendors and cloud services you work with prioritize getting updates and patches out for their open source packages and services. And this is about more than “security”: it’s just upgrading to new versions of the projects you use to get new features and performance improvements. 

You want to have the processes and tools in place to deploy those updates as soon as possible, ideally without taking down production and stopping the business from running.

The container-based applications that run in kubernetes and Cloud Foundry - both open source! - provide excellent ways to do this nowadays. For example, the US bank Wells Fargo runs many applications in containers and because of how open source is packaged and managed in their platform, they’re able to deploy updates multiple times a week without disrupting their applications and, thus, business. I’ve seen this across banks, government agency, retailers: you name it.

So what you see in our second survey, here, is that with the right tools and process in place, and managing how your open source is packaged, you can get tremendous benefits from cost savings to developer productivity. The added bonus is that these same controls for open source can be applied to your own code and software. Securing open source is important, but the more important problem to solve is securing your own software. That comes down to the same thing: tools, process, and package management.

Once you have those controls in place, you can get that innovation engine going.

Here’s what I’ve learned in doing 30 (maybe more like 40?) executive events in person and online over the past four or so years. Over my career, I’ve done these on and off, but it’s become a core part of my job since moving to EMEA to support Pivotal and now VMware Tanzu with executives.

At these events, I learn a lot about “digital transformation,” you know, how people at large organizations are changing how they build software. But, below are some notes on what I’ve learned about doing the events themselves.

The events

These usually get together a of 8 to 12 people who’re up “upper management” and involved in changing organization structure, practices, and “culture” to get their groups better at software. They’re usually very large companies: banks/insurance, manufacture/pharma, government, etc.

We used to host dinners, in person to meet these people and tell them about Pivotal, now VMware Tanzu. These dinners were eight to about twelve people. You have pre-dinner drinks and hanging out, sit at a table and eat a meal (fish, meat, or chicken - usually very good from a luxury hotel kitchen), discuss “digital transformation” during dinner, and then have drinks on the bar with about four or five of the attendees who stay.

This doesn’t work when you’re in lock-down for two years now. So, we shifted to doing these events online. I’ve been the primary anchor - the entertainment, as it were - for something most of these in Europe that are in English.

When we started, we didn’t know if they were going to work or how and had to figure it out along the way. Now, we’ve got a good formula and here are some things that work:

1. First, the format, or “run of show”: fun chit-chat as people join the meeting, an introductions round, the novel event, a short presentation to establish the topic and provoke some questions, open discussion, and then a thanks and tiny vendor pitch at the end.
2. Do an introductory round at the start. Each person gives their name, title/role, what they’re working on, and most important what they’re looking to get out of the event. This is good for both parties (vendor and attendee) to get to know each other, and their interests good. It also comes into play in moderating the discussion at the end. For discussion in the group, this part is really handy because it lets everyone know what people will be interested in talking about.
3. Have a “novel event,” a fun activity some kind that often involves something you’ve sent the attendees. For most of these, we’ve had a sommelier do wine tasting. We ship three little bottles of wine to each attendee and the sommelier walks through each wine for about 30 or forty minutes. The one we work with is fantastic, telling the history of the wine and the region it’s from more than the mechanics of drinking. We’ve also had beer tasting, and in the States they’ve done bourbon tasting. For Christmas we did gingerbread tasting. I once ran a Nutella tasting. A nice dinner is the “event” of an in-person round-table, and you need a hook for these online ones.
4. Alcohol is a good ice-breaker and the best event to have. I don’t know what to tell you: it works and people appreciate getting free wine. The wine is good, but the stories and conversation around the wine get people’s in a sort of learning/thinking mode.
5. For online events, have a PowerPoint. I use that word instead of presentation because it evokes the most cringe. For in-person events, interrupting a sit-down dinner with someone going up and presenting slides is practically taboo, and certainly weird. It just makes things too commercial and introduced a formal tone that messed up the conversation. But, online, things are very different. We ended up coming up with a 10 or 15 minute presentation that basically describes what good software development looks like with a few customer examples: “product, not project” to use one framing. I found that doing this is much less about discussing exact technologies (or “vendor pitching”), and more about level-setting what we’re going to be talking about, introducing topics and problems to discuss. It’s important to have at least one story that illustrates this point. The mechanic of this presentation is to say “this is what we’re talking about, here’s a language for it, and here is one example we can refer to.” Without a shared vocabulary and some anchors, you’ll end up spending all of your discussion time on definitions. This defines “the what,” the end goal that attendees are shooting for. Most people are struggling with “the how” of getting there. So, at the end I put up a list of common hurdles and problems. This is what drives the third part:
6. Moderated open discussion about people’s challenges and successes in changing their organization (transforming). I end my little presentation with a list of about ~15 common hurdles. Then I ask people to share their stories, things that have worked, that they struggle with. Sometimes getting people to start talking is like pulling teeth. I’ve had to specifically call people out before. But, often there’s at least one person who will start with a story, e.g., “you listed finance as a problem. I agree, we are struggling with getting finance onboard with shorter development cycles and being open to changing plans.” At that point, people start talking, often even giving advice to each other. I love this part!
7. After the first few comments, this is where I’ve forced myself to do actual conversation moderation. I say forced because, if you know me, you’d be shocked that I would be doing this - I don’t like talking with groups. I’ve learned to figure out the people who are talkers, the ones who are reluctant to talk, and to balance out the two. This requires two things: predicting a topic that someone could comment on and abruptly changing the topic of conversation, often by calling on someone new to talk. Predicting what people can talk about is usually drawn from the introductions, or past comments they’ve made in the chat. You don’t want two or three people to dominate the conversation, which is a common risk. So you have to draw people in. To do this, you can ask them directly to follow up, or you can just change the topic of conversation all the sudden and have them kick it off: “Those were some interesting comments on dealing with finance. Now, I’m interested in how you’re dealing with legacy systems. In the introductions, it sounded like the bank Alexandra works with had a lot of legacy systems: Alexandra, how have you been dealing with that?”
8. At the end, you wrap up by saying “let me tell you a little bit about what we actually do and how you can engage with us more.” If you keep this to five minutes and thank everyone for showing up, it’ll be fine and not too “don’t do a vendor-pitchy.”
9. In person events are slightly different. There is no presentation. Instead I have to sort of wing it and rather than being methodical and laying it all out (a presentation!), I just talk about what it means and looks like to do software better: the practices, an example story, what new tools make all this possible, and a few common hurdles. This generally works to get people to the open discussion, which is the goal of these get togethers. I’ve gotten a little rusty at this as all the events have been online for the past two years, but after a couple so far, I’m starting to remember how to do this.
10. For in person events, I think it’s handy to have about 30 minutes of hanging out before things start, and even an event or some type. Most recently, we did a Formula One simulation game. An event is always fun and relaxes people, but all of this time also allows me to meet people and find out what they’re interested in. It’s totally workable (and not weird) to ask people what they work on and what they want to get out of this event. People will just tell you - and happily! And then you can start up conversations with them that you later draw on.
11. Again, the goals of all of this is for people to get to know one another and learn from each other. You can do a surprising amount of that in 90 to 120 minutes. I think this is because people are genuinely interested and engaged/learning and because my co-hosts and I have learned how to moderate and drive conversations.
12. Sometimes, instead of my short presentation, we’re lucky enough that to get one or two customers to speak. These are great, I usually I ask a few questions and sometimes the customer does a short presentation. We’ve had people from Audi, Rabobank, Daimler, Tesco Bank, Cerner, and other places. When you do this, you of course need to spend time with the person up front: not so much on content (you should let them talk about whatever they want however they want), but more just get friendly with them to set the tone of the meeting. And, of course, it’s a chance to meet and learn from someone new! Having a customer talk is always preferable, but rare to be lucky enough to get.

Behind the scenes

I don’t do much or the behind the scenes work for these, and it’s a lot of work. I’ve been very fortunate to have the support, belief, and, really, my ongoing nurturing/training from my co-workers who actually run all of this. My friend Hinada Neiron has done a lot of that work and she’s done a great job putting up with me and making sure I don’t slack.

Here’s the behind the scenes stuff that happens:

1. Finding and recruiting the attendees. I’m not too sure how this happens as we work with an agency that helps us. They’re great at it. Also, sales people and inside sales people also try to recruit people. I haven’t done much work here: I think I got two people to show up. The problem here is that you’re trying to meet new people, so you need to find them.
2. The agency also reminds people to show up and will call them if they haven’t shown up yet (like, on the phone!). This actually works well and brings in people who wouldn’t have made it otherwise.
3. We spend a lot of time on the landing page/description of the event. At first, I thought this was too much, but I’ve come to realize that it needs to be near perfect because people you’re inviting don’t know us too well or what we do, so we need to get their attention and interest.
4. It’s important to make notes and plan followup right after the last person leaves. It’s then equally important to talk directly with whoever it going to follow-up with customers. The goal of these events, on the vendor side, is meeting new people to start working with, so you have to push your people to do that.
5. I send a thank you to all the attendees on LinkedIn, asking to connect with them. And, we of course send a thank you email.
6. Ongoing, I think it’s good to discuss with the team what’s working and not working, to come up with new things to try, and always be trying to make things slightly different. You don’t want to get stuck doing the same thing every time, otherwise you won’t find new things that work even better. Also, it just gets boring if you’re not experimenting a little here and there.

My own transformation

Overall, these events are great. As you can probably tell by some of my comments above, it’s not natural for me to talk with groups of strangers, or even individuals. I go out of my way to avoid it on my life - I love self-checkout!

So, I was very worried about that at first, but with encouragement, just doing it over and over, and also experimenting with what works and doesn’t work, I’ve gotten over it.

Most of all, I’ve made sure I enjoy these events by talking about things I’m interested in and asking people whatever questions I’m curious about. You could call this “listening,” which I suppose it is. Several years ago when I was talking about this nervousness with my wife, she reminded me that I love talking about tech stuff, and learning about it…and that’s exactly what we talk about at these events! Once I realized that these were the kinds of conversations I wished I could have all the time and people I wanted to meet, it was easier to transform myself a little bit.

Anyhow, they’re good events, and I enjoy them. Hopefully I’ll see you at one of them!

Looking at four months of numbers, here’s my theories of how to get more attention for my enterprise tech videos:

1. Make short ones, each with one point - 1 minute to 10 minutes.
2. Post the videos natively to Twitter, YouTube, or whatever channel - don’t rely on people clicking on YouTube.
3. YouTube is, in general, the worst performer for eyeballs.
4. LinkedIn is the best all around performer (but, I haven’t found detailed analytics, like seconds watched versus just auto-play).
5. I haven’t done enough analysis of CTAs (“click here to go to my landing page and move further along the sales funnel to giving us CASH!") but they’re near impossible - Twitter looks good, but I don’t have enough visibility into the end-to-end funnel.
6. Thus, following 5: focus on ideas you want in people’s heads (brand, thought lording, reputation, etc.) over clicks/transactions.

Analysis

I do a lot of videos for my work - selling kubernetes and appdev stacks for enterprises, along with the services/consulting that go with it (hey! VMWARE TANZUUUUUU!). Over the past two months I shifted from longer form vidoes (30-50 minutes) to tiny ones.

Sort of counter-intuitively, tiny videos take just as much work as long ones - lots and lots of editing, making subtitles, making zaney thumbnails, and all the usual uploading posting around. Sometimes tony videos take more work than just uploading longer, 45 uncut minutes.

The results are dramatic though: the shorter videos I do get a lot more views and “engagement” than the longer ones. This fits common SEO, social/influencer hustler folklore: no one likes long form content. After over 15 years of podcasting and presenting and blogging, I know that folklore isn’t, you know, universally true.

The Charts

The following tables are incomplete, it focuses on the tiny videos. See the taller table that follows for the numbers for the longer videos. (Click for the larger version of each chart.)

Table 01 shows the Dec 2020 and Jan 2021 tiny videos I did. I’ve been very time constraint of late (we have to - er, get to - home school a seven and ten year old, and also need to watch a 10 month old), so I’ve shifted to doing these small videos in the time I can find, often when I’m taking my baby daughter on a walk and she finally falls asleep:

Table 01: Tanzu Talk tiny videos (and some long), Dec 2020 to Jan 2020.

Table 02 shows the tiny videos I did back in the Spring (2020). I was similarly time-constrained - technically (and, mostly - hey, my therapist has helped me recognize that I’m a workaholic, but, like, the content I produce for work is my passion - my work isn’t just yelling at supply chain people and arts and crafting PowerPoint slides and pivot-tables…OK…I’ll take a breath…) I was on paternity leave, so I had to snatch the times I could. I uploaded these videos to my personal YouTube site (the Dec/Jan ones are on the VMware Tanzu channel), so their YouTube views are shit:

Table 02: cote.pizza tiny videos, Spring 2020.

I call these “cote.pizza” videos because that’s the URL for a CTA I had.

Then, for comparison, Table 03 the views for all the Tanzu Talk videos - most of them are long form and were only hustled with YouTube links in Twitter, LinkedIn, etc.:

Table 03: All Tanzu Talk videos, tiny and long, 2020

Findings

There are some key findings:

1. The short videos get a lot more traffic.
2. Posting the videos natively to Twitter and LinkedIn gets a tremendous amount more traffic than posting links to the YouTube videos. You can see this in Table 01: the videos in December were promoted with links to YouTube, but the ones in January were posted natively to Twitter and LinkedIn. (Some videos were previews of longer ones, like the DevSecOps for Fed one).
3. I haven’t done a video-by-video analysis, but very few people (if any) will click on a link to YouTube that I post in Twitter or LinkedIn. I don’t know if they click on CTAs either. (There’s some views from Instagram, Facebook, and even TikTok too, but I’m leaving those off from this write-up - they’re not high or consistent enough to consider - you’re better posting Nutella videos to those channels.)
4. I have no proof of this, but I think adding in subtitles helps. Instagram will auto-generate sub-titles for you, and you can rely on YouTube’s auto-generates srt’s to upload to LinkedIn and Twitter, but I’d use something like Descript to make a “perfect” srt file.
5. My Minecraft Yeller Thumbnails are the radest shit you will ever see in b2b marketing. COME AT ME. (I discovered Adobe Spark Post which is fucking awesome for this shit.)

Concerns/open questions

The major component I’m missing is following what happens when people click a CTA link. I encoded most all links I use for attribution to me, but I, of course, didn’t tell any of our web-funnel acquisition people this, so I don’t know how get those numbers. This would be extremely valuable info.

On the other hand, the price range of software and services (six to seven figure deals) I help sell is so high that having just one click, or just someone having seen and been influenced by my video evne though clicked nothing trackable.

Also, I’m concerned about echo chambers. Many of the “engagements” (likes and stuff) I get are from co-workers, which I value tremendously! There are, though, a sort of knowable set of “customers” who also engage. I need more insight into how far out of the echo chamber I’m reaching.

Let me state this clearly: I have no idea if all of this is helping the business. BUT IT SURE IS FUN TO DO!

All of that aside, let me tell you a (depressing?) secret: the only thing people care about are raw views. There may be some quibbling about completion rates, CTA following, etc.: but at the end, people will just remember the raw numbers. (Still, I’d like to have more visibility into the money I’m helping bring in and retain, but, hey, as I like to say, “I get paid either way.")

Next to try

1. “Everyday someone’s born who never watched The Flintstones" - Looking at the numbers, not that many people have seen my longer form videos. Very few have watched to the end. If I slice-up and reserve some of those at tiny videos, it won’t be feed them left-overs reposting, it’ll actually be new for many people. I think this is something that us insatiable, completist readers don’t get and why we find re-posting/ICYMI’ing so vile.
2. People love stuff about auditors/governance and security…but, really, you can’t predict what people like.
3. Post in LinkedIn - you’ve got ten minutes, that’s a lot more than Twitter’s 2m30s.
4. In Twitter, you can share access/use for the videos with other people. I need to share this with the people who run @VMwareTanzu and other accounts and see what success they get with posting those videos natively. Based on purely gut feel after looking at some of the videos, this will drive a lot more eyeballs.

Oh and… HEYYYY, GUYYZZZ! Three, two one! LIKE AND SUBSCRIBE BELOW!!

Appendix

Some additional notes as I think of them:

1. Many of the longer form videos were streamed in Twitch at first. For my stuff, there’s around, I don’t know, 30 maybe 50 or 60 views after streaming in Twitch. During, it’s like zero to five, but usually, like one or two. I don’t really consider Twitch to be, uh, the “right fit” for my content. I think my co-workers who actually code (that’s like watching someone game, right?) have much more success.

I’ve tracked at least three different definitions of DevOps since the days of “agile infrastructure”:

1. Using Puppet and Chef (and then Ansible and Chef) to replace Opsware and BladeLogic.
2. Full stack engineers to setup EC2, load-balancers, and other Morlock shit.
3. Full stack engineers are bad, but sort of the same thing. Also, you can’t have a DevOps “group” or title. But, you know, someone should do all that automation.
4. Putting all the people on one team, having them focus on a product, and establishing a culture of caring and learning.
5. SRE is not DevOps.

So…actually five. Maybe some of them just being footnotes on the evolving concept. (And, if you, dear reader, feel these are wrong, then let’s compromise and make the list six.)

All of them evolved around bringing down The Wall of Confusion, allowing “developers” to deploy their software to production more frequently, weekly, if not daily. And, of course, making sure production stays up. (You’re supposed to call that “resiliency” and instead of SLAs use SLOs and some other newly named metrics that answer the question “IS MY SHIT WORKING?” Whatever you do, just don’t say “uptime," or you’re in for it and will be relegated to running the AS/400’s.)

I used to snide that the developers seemed to have been yanked out of DevOps, sometime around 2014 and 2015. All the talks I saw were, basically, operations talks. I haven’t really checked in on DevOps conference talks recently, but at the time, I don’t think there was much application development stuff. (I’m not sure if there ever was?)

None of this means that DevOps is not a thing. Not at all. It just means that the enterprise finds its own use for things. It also means there’s still weekly write-ups of what DevOps is - you know, those ones that are always lists of ideas, things you’re getting wrong, and how to start.

Autonomous product teams

Nowadays, I try to stick to that fourth one: you want to set up autonomous teams that have all the skills and responsibility/authority/tools needed to “own” the software being specified, designed, developed, and run. This means you have to, basically, remove-by-automating all the operations stuff it takes to stand-up environments, deploy things, and do all that “day 2” stuff.

(HEY! HEY! WANT TO BUY SOME ENTERPRISE SOFTWARE?!)

Now, I think this product-centric notion of DevOps is, well, kind of an over-extension of the term “DevOps.” But since SRE has sucked out the “ops” part (but, remember, dear reader, don’t commit the embarrassing act of saying SRE is DevOps - no, no, you’d never do that, right? SO SHAMEFUL! (SRE is totally different - no overlap or similar goals shared between them at all. I mean, they have separate groups, silos! COME ON!)), slicing “DevOps” back to just “Dev,” but with a product-not-project focus isn’t too shabby.

Anyhow. I came across a good overview of this product notion of DevOps, all the way back from 2016, while re-reading Schwartz’s evergreen excellent The Art of Business Value:

Agile approaches attempt to bring together developers and the business in an atmosphere of mutual respect and joint contribution. Until now, however, the focus has been on users of the software, product visionaries, and developers. Recent developments in the Agile world—notably DevOps—have broadened this idea of respect and inclusion to encompass Operations and Security. The DevOps model, in other words, looks to break down the silos that have resulted from technical specialization over the last few decades. But the DevOps spirit goes further, looking to eliminate the conflicting incentives of organizational silos and the inhumane behaviors that can result from those conflicting incentives.

Perhaps we can take this idea even further still. There is no reason why the DevOps team’s responsibility needs to stop at the border of what used to be considered IT. The team is part of a broader enterprise, whose collective knowledge, skills, and judgment need to be part of the value creation process.

Look a' that guy! Business Value just effortlessly jets out of his pores like a peripatetic thought-monarch!

This is from an executives' perspective, but it drives home the point we’re always trying to get to with software: doing whatever it takes to figure out, create, and give users features that are actually useful to them. Somewhere beyond that, if you’re lucky, it’ll help out “the business.” Also, it should implement The Unspoken User Story: user would like software to actually work.

As a DevOpsDays sponsor you’re often given the chance to give a one minute pitch to the entire audience. Back stage at DevOps Rex, this week, I was talking with a first timer. One minute seems like such a small amount of time: how could you say anything consequential in 60 seconds? You’re presenting in front of the full audience, anywhere between 150 to 500 people. They probably also loath vendors, or, at least are bored by them. The stage in Paris is intimidating. It’s a huge room in an old cinema, imagine the most stereotypical movie theater from whatever “the golden age” is: double decked seats, a huge screen. Plus, the organizers are meticulous: there’s a rehearsal for these 1 minute pitches in the morning. Like a full one where you’re given a minute to talk. Normally, these pitches are very informal. Overall, it can be a public speaking challenge…plus you have to get up an hour earlier than normal.

People get rattled by these 1 minute talks and they can also give boring pitches. Here’s what how I think about them and what I do:

1. The goal of this pitch is to tell people the name of your company, what you do, and to get them to come to your table to talk more.
2. So, tell them the name of your company, what you do, if you have time, the story of a customer who did something remarkable, and give people a reason to come to your booth.
3. People will come to your booth if you give them something: books, socks, flash lights, whatever. More senior, “decision makers” also want free stuff (they’re not monsters!), but they’ll also come to see how you can help them accomplish their work goals.
4. If you can tell a joke, even a lame one (of course, not an offensive one), do it, usually towards the start of your pitch. Getting a room full of people to laugh gets them engaged and listening closer. Your pitch more memorable, and also will give you a confidence boost to coast off for the next 45 to 30 seconds.
5. Finally, if you screw up, it does’t matter. It’s just 60 seconds so it’ll be over quickly and people will still come by your booth if the organizers have done their job for vendors: arranged the sponsor booth placement to drive foot traffic.

Figuring out what to say

The people like socks.

Despite how disorganized and spontaneous I may appear (that’s part of my well planned out and cultivated schtick, a safety valve for when I haven’t prepared, plus it’s a fantastically caustic feedback loop for my self-loathing — yay!) I usually prepare content before each talk.

I write a bunch of points down and reduce it to three points that I want to make. As I wait to get on the stage, I go over these three points my head; I usually write them down and look at them. Ask the local sales people what the make up of the audience is (are the developers, ops people, management, or just a general audience?), and any local events they want to drive people to.

Now, I often forget most, if not all, of that content, but that’s fine, really. Some of it will show-up. And definitely don’t let your three points constrict you, just use them as a fallback and a suggestion.

Being at a DevOps event, you should probably talk about how your company relates to DevOps. I tell people that Pivotal Cloud Foundry removes all the toil of lower-level automation that DevOps is looking to eliminate, the A in CAMS. It makes DevOps real, solves you DevOps problems, et. al., so you can get to the whole reason (the “outcome,” in business speak) for doing DevOps: creating better software and running it reliability in production.

De-wooding

The main thing you want to avoid is being stuffy. If you’re wearing a sports jacket (without being ironic), I’ve found that you’re more likely to give a stuffy talk — someone like Damon Edwards can sports-jacket all day, but he’s the exception that proves the rule.

If you’re just naturally wooden in public speaking situations, try to say something about your involvement in the pitch: how does it make you feel and how do you relate to it? Talking about yourself is easy as you’re the expert on the topic and have hopefully been there the whole time.

A little bit of humor goes a long way in these tiny talks. For example, Pivotal’s main product is well known for being more expensive than free, but it works and changes the fortunes of organizations that use it. That’s a good thing to joke about (“good thing it actually works ’cause it ain’t cheap”), or weird branding names (“for some reason, we call these ‘platform engineers’ rather than ‘SREs’”). I sometimes make a joke about PaaS, the cloud category Pivotal Cloud Foundry is in: “remember PaaS from five or so years back? It was terrible! Well, we’re a PaaS, but we doesn’t suck so much this time, it actually works!”

Don’t worry about it

The stakes of this pitch are extremely low. Look at it as more of a learning experience for yourself, practice for next time. If you biff, nothing bad will happen unless you work for shitty management that punishes you for 60 seconds of time (start looking for a new job — Pivotal is hiring!).

Some people like to memorize pitches, which is fine if that helps you. Most of all, the way to succeed at these pitches it to have fun, be playful.

You’ll be fine. Good luck!

Coffee is for coders.

Whether you’re doing waterfall, DevOps, PRINCE, SAFe, PMBOK, ITIL, or whatever process and certification-scheme you like, chances are you’re not using your time wisely. I’d estimate that most of the immediate, short-term benefit organizations get from switching to cloud native is simply because they’re now actually, truly following a process which both focuses your efforts on creating customer value (useful software that helps customers out, making them keep paying or pay you more) and managing your time wisely. This is like the first 10–20 pounds you lose on any diet: that just happens because you’re actually doing something where before you were doing nothing.

Less developer meetings, more pairing up

When it comes to time management, eliminating meetings is the easiest, biggest productivity booster you can do. Start with developers. They should be doing actual work (probably “coding”) 5–6 hours a day and go to only a handful of meetings a week. If the daily stand-up isn’t getting them all the information they need for the day, look to improve the information flow or limit it to just what’s needed.

Somewhat counter-intuitively, pairing up developers (and other staff, it turns out) will increase productivity as well. When they pair, developers are better synced up on most knowledge they need, learning how all parts of the system work with a built in tutor in their pair. Keeping up to speed like this means the developers have still less meetings to go to, those ones where they learn about the new pagination framework that Kris made. Pairing helps with more than just knowledge maintenance. While it feels like there’s a “halving” of developers by pairing them up, as one of the original pair programming studies put it: “the defect removal savings should more than offset the development cost increase.” Pairs in studies over the past 20+ years have consistently written higher quality code and written it faster than solo coders.

Coupled with the product mindset to software that involves the whole team in the process from start to end, they’ll be up to speed on the use cases and customers. And, by putting small batches in place, the amount of up-front study needed (requiring meetings) will be reduced to bite-sized chunks.

It takes a long time to digest 300 pages

We’re going to need a lot more coffee to get through this requirements meeting.

The requirements process is a notorious source of wasteful meetings. This is especially true when companies are still doing big, up-front analysis to front-end agile development teams.

For example, at a large health insurance company, the product owner at first worked with business analysts, QA managers, and operations managers to get developers synced up and working. The product owner quickly realized that most of the content in the conversations was not actually needed, or was overkill. With some corporate slickness, the product owner removed the developers from this meeting-loop, and essentially /dev/null’ed the input that wasn’t needed.

Assign this story to management

Staff can try to reduce the amount of meetings they go to (and start practices like pairing), but, to be effective, managers have the responsibility to make it happen. At Allstate, managers would put “meetings” on developers calendars that said “Don’t go to meetings.” When you read results like Allstate going from 20% productivity to 90% productivity, you can see how effective eliminating meetings, along with all their other improvements, can be on an organization.

If you feel like developers must go to a meeting, first ask how you can eliminate that need. Second, track it like any other feature in the release, accounting for the time and cost of it. Make the costs of the miserable visible.

This concept of attending less meetings isn’t just for developers,The same productivity outcomes can be achieved to QA, the product owners, operations, and everyone else. Once you’ve done this, you’ll likely find having a balanced team easier and possible. Of course, once you have everyone on a balanced team, following this principle is easier.Reducing the time your staff spends in meetings and, instead, increasing the time they spend coding, designing, and doing actual product management (like talking with end users!) get you the obvious benefits of increasing productivity by 4x-5x.

If you feel you cannot do this, at least track the time you’re losing/using on meetings. A good rule of thumb is that context switching (going from one task to another) takes about 30 minutes. So, an hour long meeting will actually take out 2 hours of an employee’s time. To get ahold of how you’re choosing to spend your time, in reality, track these as tasks somehow, perhaps even adding in stories for “the big, important meeting.” And then, when you’re project tracking make sure you actually want to spend your organization’s time this way. If you do: great, you’re getting what you want! More than likely, spending time doing anything by creating and shipping customer value isn’t something you want to keep doing.

It may seem ridiculous to suggest that paying attention to time spent in meetings is even something that needs to be uttered. In my experience, management may feel like meetings are good, helpful, and not too onerous. After all, meetings are a major tool for managers to come to learn how their businesses are performing, discuss growth and optimization options, and reach decisions. Meetings are the whiteboards and IDEs of managers. Management needs to look beyond the utility meetings give them, and realize that for most everyone else, meetings are a waste of time.

For more on improving software in your organization check out my 49 pages in a fancy PDF on the topic.