(I’ve had a little email newsletter for sometime. It’s fun! People like it and write to me! Rather than rely on the archiving at TinyLetter, I thought I’d post the archives here. However, feel free to subscribe to the newsletter in its proper format, email…or just read it here, whatever you like.)
Hello again, welcome to #28. Today we have 33 subscribers, so we’re +/-0. I’d love to hear what you like, dislike, your feedback, etc.: firstname.lastname@example.org. (If you’re reading this on the web, you should subscribe to get the daily email.)
See past newsletters in the archives, and, as always, see things as they come at Cote.io and @cote.
Tech & Work World
The DevOps Landscape
I need to put together a stronger DevOps research agenda at work. We actually have a great paper from 2010 that Jay Lyman wrote, but there’s a certain systematic set of material that’s good to have on most topics.
In 451 speak, here’s the body of work I’d want to see over the course of a year on the topic:
(1.) Define DevOps with a taxonomy and “landscape”
(1.a.) Write down and categorize all the relevant vendors and projects
(2.) Write a Spotlight defining the space, going over concerns/best practices for buyers (“enteprises” or “end-users”), vendors, finance (these could be separate spotlights)
(3.) Write a SectorIQ [this covers potential acquisitions in a space] going over startups in there
(4.) Write a TBI [30-40 page PDF, “long form report”] or Spotlight that’s a “buying guide” targeted at enterprises that goes over how short-list options. For DevOps, this would include numerous open source projects as well.
(5.) Do all the usual weekly company coverage of people in the space as defined by 1.a.
You know, just a short list of stuff.
To that end, I started a mindmap to think about how to slice up “DevOps” and eventually list vendors, projects, and practices that would drive our research and what we focus on. The mindmap is likely to be thrown-up all over, thrown away, and evolved; I think I’ve spent about 15 minutes on it so far. But I’d be curious for pointers and thoughts on how to put this all together.
A cursory lmgtfy brings up numerous other slices at this over the years:
I need to do the above for two primary reasons:
- We’re getting lots of inquiry from vendors, enterprises, and finance to understand the space. They just want to definitive coverage of it.
- I need to narrow down our focus on DevOps and add in the discipline of having a “list” of topics we regularly cover.
It goes without say: I’d love your input!
P.S.: is MindMeister the best option if I don’t want to shell out for MindManager?
How to do a webinar for analysts
I was doing a webinar today, and when it was my time to be quiet, I tapped in some tips on what analysts are supposed to do in webinars (I guess in addition to paying attention when they’re not talking ;>).
The framing is that analysts are often brought in to do webinars with vendors. The commercial goals are to (a.) help draw an audience, and, (b.) get some credibility and interesting content from the analyst. In other words: it’s a marketing activity, from the vendor’s view point. Typically, the analyst speaks to “macro trends” for half of the webinar, the vendor pitches how their product helps you, the customer, profit from those macro concerns, and then there’s question and answer. You do webinars for thought leader and lead-gen.
In no particular order, here’s some tips for analysts doing vendor webinars:
- Timing is critical, webinars often involved more than one person, so you’re stealing time from others if you go on.
- Don’t mention rival vendors or “solutions” in any but the vaguest way.
- No need for a lot of context setting and explanation, just focus on simple direct things without educating too much - need to move quick.
- Try not to sound bored.
- Don’t be dismissive of the core concepts under discussion, e.g., “cloud, you know, some people like it.”
- You’re setting up the audiences minds to listen to the vendor pitch, so leave them thinking happy thoughts.
- Cut out parenthetical asides, they take up time.
- Practice and write-up your talk, even if you don’t read the script. This is a performance, not a “talk,” discussion, or a podcast.
- Live vs. recorded. Doesn’t matter that much, but economics of webinar mean little to no editing should be done. There’s really no benefit to being live.
- Q&A: from audience is good for your own input, or canned.
- Slides should match talk. In this instance, you kind of are reading the slides, it’s not keynote stuff. But, be brief. If you have 5 points in a slide - 5 data points on a chart - just talk about 3 or 2 to cut down time.
- Give the vendor lots of time to talk, unless they don’t want to.
- For the vendor: Publish a recording for maximal value.
- For the vendor: demos are a nice thing to do.
Fun & IRL
What’s more fun than tips on doing webinars?!