I put up another gravy podcast episode this afternoon. It’s pretty crackly, which is terrible. I need to figure out the secret to recording with the iMic without it sounding like shit.
We spend our lunch break talking about The Undercover Economist, Aidan’s (Matt Ray’s son) complexifying music, the DCMA, The Long Now Foundation on world population growth, and other exciting topics. It’s a non-technical (relatively) episode for all those people who fell asleep listening about state-machines…
(This episode edited by Coté)
Since I spent sometime a couple months ago putting together a presentation on logging in Java, I thought I’d submit a proposal to JavaOne this year. Here’s the proposal I wrote up:
Logging in Java ™ with java.util.logging
This presentation shows you how and why to use the logging API that’s
bundled in the core J2SE library. You’ll learn the basics of logging
and configuring, advanced logging and configuration, how to tailor
logging to your needs, and best practices for logging.
We’ll go beyond the standard documentation available in the J2SE and
on the web, using plenty of examples to explain pragmatic ways to
quickly and effectively use the logging API in your code.
The built in logging API has been available in the J2SE for several
years, but consistent and knowledge use of this API is sparse. This
despite both the richness and simplicity of logging, not to mention
the consistency and portability benefits of using the bundled logging
Logging is vital for both quick debugging during development and once
your software has been deployed onto hosted servers or in the field to
customers. Oftentimes all that stands between you and hours of
debugging over the phone is the ability to quickly use logging to
diagnose problems remotely. Attending this session will help save you
from those tedious and costly hours, keeping you and your customers
The presentation follows the outline below:
What logging code looks like
A quick dive into what logging with the logging API actually looks like in
code and as output.
When and why to log
Why programmers should bother to thoroughly put logging in their applications:
the primary reason being that once your application is run in a non-developer
environment, in production, it becomes almost impossible to debug. As a result,
customers get frustrated as problems take “forever” to fix, and companies spend
too much time and money diagnosing problems in the field.
The Logging API
This section introduces the different concepts in the logging API: log
levels, the different log messages, handlers, formatters, etc.
It also covers best practices in logging, such as when to double check
the logging level for performance, using argument’ed messages, logging
exceptions, and how to determine where in the code to log.
Finally, this section covers how to configure logging using the
default flat files, at runtime, and with the newly available logging
MBean. Knowing how to properly configure logging, especially during
runtime is an invaluable skill.
This section contains many code examples that illustrate the points.
This section covers the customizations that can be made in the logging
API, such as custom handlers and formatters, as well as some
extensions to logging, such as context loggers that take care of
logging tedious to code, but vital to debug, information.
A brief section covers using Aspect Oriented Programming to help weave
logging in; pit-falls of an AOP approach are also covered.
Logging Grab Bag, Tip and Tricks
The last section collects together a “Top 10” style list of tips and tricks
with the logging API.
If you’re interested in taking a look at it, there’s a draft of the presentation available.
And, of course, if you’re interested in me giving the presentation, feel free to contact me and we’ll work something out: I’m sure it’d be fun ;>
If you haven’t been keeping up, there’s several new gravy podcast episodes available. You can also, of course, subscribe directly to the feed: there’s plenty of one-click subscribe buttons available for you one-click addicts.
In this episode, we talk about Charles’s intuition experience of late, java profilers, and getting a good shave in Austin.
If you’d like to leave a voice comment, please call +1-512-879-6339 (it’s a US number) or Skype us at drunkandretired, and leave some voice mail. Otherwise, you can email comments to firstname.lastname@example.org, in the comments field below, or by talking directly to one of us bozos.
Also, check out the new episode of the quick and dirty DrunkAndRetired.com podcast: Gravy.
(This episode edited by Coté)
I updated to the new Java release on OS X today, and it broke my use of XSLT in Java. From what I’ve read, J2SE 5.0 no longer sets the system property that tells JAXP which TransformerFactory to use. This, of course, seems kind of silly. I’m sure there’s some long, drawn out explanation of why: the upshot is that shit don’t work for me.
To get around this, you have to pass in the following system property to all your Java processes that are going to be running XSLT:
This bug report from maven has some more detail.
When bookmarking or link posting, it’s proper etiquette to put in a “via” that indicates where you got the link from. I do this a lot in my own bookmarks in the descriptions, e.g., “(via mray)” or “(via sog)”. That great wunderkammer, boingboing is the prime example of this behavior, they’re really good at doing it.
For quite sometime, I’ve been fretting over whether I should do vias in del.icio.us as tags instead of parenthetical stuff in the descriptions: if I got a link from Matt Ray, I’d use the tag via:mray.
- I could more easily see a list of links I’d gotten from people. I could even make a tag bundle out of it. (This is where smart tag bundles would be nice, so I could just say “put all tags that start with
via:in this bundle.) Of course, it’d mean I’d want to do a tag search like
via:*for all tags that start with
via:. I’m not sure if the del.icio.us search syntax allows for this.
- It’d be a cheap networking/link spelunking thing. If I used the same text in in the via tags as the person’s del.icio.us ID, you code something up to layer on a link between the two of them. That is, you could offer the feature: “If you liked this link, check out more links from the person who sent this to Coté”.
- I can get an idea for who sends me the most links by counting up how many via:mray’s, fro example, I have.
- People could subscribe to all links suggested by mray, scoped down to my bookmarks, or everyone’s bookmarks. That’s sort of like reverse bookmarking…or something.
- People who send me links can track the effectiveness of sending me links. That is, if I like the link enough, I’ll bookmark it, slapping on the
via:tag. So, folks who send me links can answer the question “which links that I sent Coté did he really like: like enough to go through the effort of bookmarking?”
How’s That Sound?
Yeah…. So…. Maybe I’ll start doing that. Anyone else do this? Have any thoughts?
In this episode, we get down to some nitty gritty code theory, and Coté
tells one of his favorite intuition based learning stories…again.
starting now we have voice-mail where you can leave comments:
out Skype ID is drunkandretired and the phone number is
+1-512-879-6339 (it’s a US number). We’ll still, of course, accept comments as MP3/WAV/etc. if you send them to email@example.com.
More Audio Content: Gravy!
If you haven’t checked out the Ozzie Microsoft strategy memo, you should put aside the few minutes to read through it. It’s valuable in several ways:
- It’s an example of exactly the kinds of technical leadership and communication you’d expect at a software company. A software company lives and dies by it’s developers (medium- to long-term at least: you can always vaporware some short-term cash), so it’s obvious that those are the people your most important communications should cater to and address.
- There’s a start of the “be the infrastructure, not the end product” strategy I talked about a few days ago. That is, in a more DIY/good enough programming/ecosystems culture, for a large company that needs a steady revenue stream, selling the tools is more stable than selling the actual artifacts of those tools.
- The fact that it’s out shows — intentional or not — a willingness to engage in very
-ish PR. In this new development mentality, the more info you share, the more cred you get: secrecy is for the old foggies of technology. (There are still some issues to be ironed out with non-developers, but the PR for only developers is looking sound.)
- It has a summary of Web 2.0 development (or “contemporary web-as-platform programming” for all you curmudgeons), in just 7 words: “treat[ing] the ‘raw’ internet as their platform.” The fact that a high-level exec [or his staff, etc…. whatever] can and is articulating it is significant: not to the lucky people already doing it, but to all the BigCo coders who wish they were doing it but can’t get their management chain on board.
Those are just a few highlights, there’s more to be had from it. The most significant thing, of course, is that it’s coming from Microsoft: a huge name that people who make decisions can, and will, take guidance from.
As the last point addresses, BigCo management chains rarely listen to their own highly paid developers; instead they look for outside validation of new technology directions. On that issue in particular, if you’re up on your internal marketing theory, this memo is a big arrow in your quiver. Now go shoot it.
Update: some of the ideas I outlined in another post, “The Disappearing SysAdmin and Enterprise Software Vendors” fit well with the SaaS stuff in this memo, with the change that the ideas in the memo at hand are more consumer software than enterprise software centric.
Mr. Twiggs came by to talk to me about a way to put a sort of “here’s all the links to my online self” service together. The idea is that someone such as himself (and definitly such as myself) have all sorts of different content strewn through out the web — flickr, del.icio.us, Amazon reviews, eBay reputations, static web pages, podcasts, Netflix rentals and reviews, etc. — and we want some page to point to that lists all of that stuff, that answers the question, “can I see all of Glenn Twigg’s online life?”
That is, you want a site map, but not just restricted to one site, a site-map that spans the entire web.
I don’t really know of successful system that does this yet…otherwise I’d probably be using it.
The Roach Motel
The metaphor of The Roach Motel (started by Steve Gillmor, I believe) is that all these online services tend to lock your data up in them. For example, you can’t extract and use the reputation data about you from eBay; you can only use that data in the context of eBay. Like roaches to a roach motel, once your data gets into eBay, it can’t ever leave. (Check out this edition of The Gillmor Gang from last year for an exquisite grilling of eBay’s Jeff McManus on this point.)
So, in my mind, what Mr. Twiggs is looking for is a roach motel buster: something that will layer on-top of all the websites and roach motels out there and aggregate the data into a centralized place, or, at least, view.
Roach Motel Busters
While there’s no ultimate Roach Motel Buster, there are what we’d in the enterprise software world call “best of breed” roach motel busters. For the benefit of Mr. Twiggs, here’s the ones I can think of:
- Google Sitemaps – providing a way of helping crawlers understand the important links in your site. Also see this article.
- FOAF – capturing your social networks. Among some blog software, livejournal widely uses FOAF.
- attention.xml – multi-year winner of the Will It Ever Cross the Chasm Award in Excellence…. glibness aside, it unlocks the clamp-down on keeping up with your friend’s (and own) interests. (I favor a less formal approach.)
- Erik Benson’s Megablog – Erik’s put together some scripts (I’m guessing) to centralize much of his online activity into one blog, erikbenson.com. Essentially, it pulls content from a bunch of sites (check out the “Getting Stuff From” sidebar) he puts content into, and “cross posts” that content to the megablog. It’s pretty damn cool, and I’m sure it gets info-wonks like myself all hot and heavy.
So, we can only hope that Mr. Twiggs will figure it all out for us and provide this service and/or format. It doesn’t exist yet, but it’d be a lot cooler if it did.
Update: check out Glenn’s post. Damn, I’m eloquent!
I’ve been borrowing one of the ITIL books, Service Support, from work. As someone who gets jazzed about devices that have SNMP agents on them, it’s an exciting read. So far — on pg. 43 in the service desk section — it’s been great at the simple, but rarely done, task of simply defining all the tasks and motivation that you’d expect IT to perform.
Knowledge Ain’t Cheap
The problem with these books is they’re so damn expensive. I could make my car payment with the amount I’d spend buying all the ITIL books. Unfortunitly, it doesn’t seem like there are free downloads from the OGC: I guess the UK doesn’t have the same “anything the government produces will be free” policy that the US has. Or, more than likely, they’ve figured out a loop-hole with this one.
The deal with me and books is that I like to write all in them, dog-ear them, and otherwise add in meta-information. On many occasions, I’ve been known to use the blank pages to write letters and other notes. I work books like pairs of jeans: I’m not satisfied with then until they’re broken and worn. When you borrow a book, this isn’t possible, and I keep feeling like I’m only half expieriencing the borrowed book.
Not to mention the fact that these ITIL books would be great references, which is only possible if you own the book. Need to know 18 things to consider when putting together a service/help desk? As they used to say in those Time Life commercials, read the book.
Got Any Cheap Books for Me?
So, if anyone knows where I can get some cheap versions of these books, I’d appreciate it. It could be hard-copy or PDF, I don’t really care.
It makes me think of a general rule of technology: if something is going to be commoditized, in order to keep your money-flow stable, you want to be an infrastructure provider. That is, you want to create the raw materials used by the people making and selling the commodity. But more importantly, you want to centralize that raw material.
Middle-man for Questions
Even in a seemingly peer-to-peer environment like the Mechanical Turk, there’s a point of centralization: the middle-man who connects together the node asking the question and the node who have the answer. Because the Mechanical Turk is a service instead of a downloadable server, they can avoid be commoditized out of the market, as with email servers: even if the nodes on both ends of the question/answer loop get really big and popular, they’ll still have to go through Amazon, who can slice off a little take.
Web 2.0 Services Are Middle-men
Most these fancy new apps that are on-line services that cater to developers (check out Udell’s comments in the beginning of the latest Gillmor Gang for more on that) can be, and are, in this middle-man position. What’s different from the middle-man gambits of “yore” is that the middle-man are making it easier and encouraging developers on either side of the service to layer on value and functionality.
Older web companies focused on being both the infrastructure and the sales-man. That is, they made the widgets and they did direct sales to customers. On the web, it’s easy to do both (among other examples, as Amazon and eBay do to much success), but if you have to choose one, it’s usually better to choose providing just infrastructure, and letting a bunch of other people figure out how to monetize it.
Spreading the Risk
There’s a huge amount of risk that no one will take up your service, but then again, once more than one person starts putting nice UIs and products on top of your serve, you’ve spread your risk over those two people: if one of them fails, you still have the other.
So, back to the Mechanical Turk (which is always fun to type), Amazon is hoping that someone else will figure out how to make killer apps (or, at least, “stunning apps”) out of the infrastructure it provides. And once those people figure it out, they’ll take little slices of the revenue.
Many people, Google included, have already built question/answer platforms, but, in my mind, they haven’t really done too much with them. The reason, as some of you wonks out there might thinking, is because things like Google Answers aren’t really extendible: they only do the one thing, you can’t microchunk, free, syndicate, and monazite it.
The Closed Doors of Enterprise Apps
Does enterprise software have a dog in this fight? In consumer software, this line of thinking makes a lot of sense. Profit in consumer software relies on volume: the more people using it, the lower the price you can charge, the lower the price you can charge, the more people will buy it, and the more money you’ll make off the thin margins. (Of course, you might be lucky to be in a story only market, and then price isn’t as much of an issue. I’d suggest that few in technology [Apple] are lucky [or smart] enough to be in that kind of market.)
In enterprise software, you don’t have that many users. Indeed, the more users you have, the more support you’ll have to provide, and the less money you’ll make. This support trap is even more terrible because you usually won’t realize it’s hurting you until it’s too late. (It’s a well know, dirty secret of this type of software that it doesn’t really want users, it wants money. But that’s a discussion for another time.)
So what is it that enterprise software can do with this? The problem with a service as a middle-man strategy is that vendors would have to change their perspective from being the one-stop-shop to being
maintainers of entire ecosystems built around their product. This idea is always thrown out there (hence the whole VAR and partner industry), but enterprise vendors don’t seem particularly adept at applying it: like Tony said, “you want me to take it out of your part of the take?”
All value creation is locked in the company, and extra-company developers can’t easily create new ways of using your software. Essentially, you’re leaving a lot of innovation (in the sense of “new software we could sell”) on the table.
Fat and Happy, Slow and Dumb
The problem is that once you build yourself into a one stop shop, you start getting fat and happy. And after getting fat and happy, you start getting dumb. And the next thing you know, you’re loosing money like blood from an axe to the head.
Building up an ecosystem of partners, sub-vendors, and customers can keep you from getting in this slow and dumb state. Everyone says things are speeding up now-a-days: there’s so many moves in the market, so much information, blah, blah, that you just can’t keep up! From my perspective, it’s not stuff is speeding up, it’s that all these people complaining have gotten slow, and the little dudes at the bottom finally have a way to get a dog into the big-time fights.
This of course, is the old disruption angle. While it’s getting tired to hear, it’s getting even more tiring to see how slowly large vendors respond to it.
So, if you believe the idea the threat of disruption, my suggestion is that you move your mind set from defending the chasm to building toll bridges across the it: instead of preventing others from profiting from your innovations and technologies, help them profit from them, and take a cut. The quickest way to provide that help is to simplify your systems, making it easier for other to latch onto the functionality the systems provide; that is, to make your system into a service that other layer on top of.
The Half-baked Part
The half-baked part of all this is that there isn’t really a know, effective way, to convert a company from fat-and-happy to outgoing-and-smart. So far, it seems like the only way to make money/survive in software with this type of strategy is to sell to Yahoo! or run your company so small that making gobs of cash doesn’t matter.
The Paradox of Success
That’s the Paradox of Success for enterprise software: the more successful (money) they get, the bigger they get, the more it costs to sustain them, and the harder it become to do something different, to change, because the risk of disrupting that sustaining revenue is huge. Change is a bad word at large companies, sometimes even a taboo.
The hard part of finding examples of large companies adopting ecosystems is that it’s easy to repackage old technology in new boxes. Marketing can successfully craft the story that a technology has fundamentally changed, when really, it’s just names and packaging that’s switched around. In those cases, it’s only the low-level coders who know the truth: they know they haven’t coded anything different into the systems, it’s all just the same stuff.
So then — aside from the verbosity of all this — the half-baked part is figuring out how to move a large company from the one-stop-shop to an ecosystem’ish based approach. There’s two parts: (1.) how do you sustain the revenue flow to keep feeding the fat-and-happy monkey, and, (2.) how do you change your people’s mindsets fast enough to deliver this type of market and systems that can thrive in it.
Destroy XOR Embrace
On gloomy days, I think the only way it’ll work is to apply The Kinman Doctrine, aka, FtF, that is, “Fire the Fuckers.” On sunnier days, it seems like it’s just a matter of exposing people to the ideas and giving them enough time to absorb and believe them.
It’s the classic fire and brimstone vs. love approach. Too bad the first way always seems to win out.
There are many times when I just want to record something quickly and put it up, usually when I’m driving into work and talking to myself (into a microphone, not just out-loud). And there’s also content we record during our regular podcast that we cut.
So, in order to feed the content monkey, I started up a new podcast for all that lost content: DrunkAndRetired.com Gravy!
It’s one of those “like it or leave” it type streams: there’s no promise of it being super-great. It could just be a really great recording of farting, off-the-cuff thinking about technology, or talking about total nonsense like TV news magazine shows. But, for me, it’ll be fun…and hopefully for at least one or two other people.
This week, we didn’t get together to record, so we put together
the second out-takes episode. Next week, we’ll get back to something more technical.
(This episode edited by Coté)
I know all you folks love blogging about blogging. So here’s some blogging about blogging about blogging: a list of all my posts about the conference I went to today, The Blogging Enterprise:
- Opening Keynote, Steve Rubel
- Kick-Starting The Blogging Enterprise Panel
- Sorting Out RSS Software, Tools & Technology Panel
- Some thoughts about Search/Info CMDB sparked by some lunch conversation.
- PR & Blogs – Anticipating & Managing The Blogstorm
- Blogging To #1 – Positioning Your Company As The Thought Leader
- Blogging Takes Time
- Closing Keynote: Shel Israel
As typographic/semantic note: I used square brackets to surround my own comments and thoughts. Most everything else in the real time notes posts are quotes or summaries of what people said, or an explanation thereof.
But, I have to say, it’s looking like Naked Conversations will actually have some new content in it, and not just be a re-hashing of what we’ve been reading on the web over the past year (excluding, of course, the chapters they’ve been posting ;>).
Character Blogs, The Jack Theory
“If markets are conversations. And blogs are the power tool of that, how are you gonna pull off having a conversation with a moos?”
Shel says character blogs won’t/don’t work. Someone in the audience suggests that Jack could pull one off. Another person shouts out that he could do a podcast ’cause he has a recognizable voice. Moore suggests that it’d be too much Jack, and we’d get sick of it. Others, and Moore, suggest that a blog isn’t really the right form, but a website, even with just comments, would do great.
People don’t want to interact with a fictional character, they want to talk to genuine people about how the company is doing, how it does what it does, and insider info about it’s product. [You can use blogs to help your customer feel smarter, and know that you’re the one who helped them feel smarter. BAAM!]
“Overall [blogging] isn’t as dangerous as it seems.” Less than 100 people (probably) have been fired world-wide for blogging.
We’re also reminded of the product management angle of blogs: you can invite people to check out your stuff, bloggers or no, and it’ll generate input.
A re-occuring theme is (complaining about) how long blogging takes. People bring that up time-and-time again. Shel Israel says that it’s talking directly to/with your customers, so it’s worth it.
People: Joel Greenberg, GSD&M (moderator); Charles Bess, Fellow,
EDS; John Moore, Principal, Brand Autopsy; Scott Rehling, Producer,
The University of Texas Longhorn Football Vlog; Todd Watson, On Demand
(As a side note: there’s a screen behind the panel. The moderator’s
intro usually contains some slides; then the screen usually contains
the names of all the panelists and their URLs. That’s pretty damn
nice, compared to other panel discussions I’ve been at recently [e.g., Lone Star Software Symposium] that just have little paper “name-plates.”)
Blogging from the Middle
Watson: People in the middle of the corporation, like IBM, can now
get their voice out there, showing off the thought-leadership that a
company has previously locked up.
But, we can’t give you a specific instance where we gained
business. It’s still too fuzzy.
Rehling: again, using blogs as a real-time feed of what’s
going on…and not allowing yourself to be sound-bited.
Moore: people are starved for more info.
What About the Company That Doesn’t Have Anything to Say?
…or “why does Procter and Gamble need to blog about Jiff?”
Moore: if your product/service is selling, you have something to say.
And, if your product is a commodity, by starting a conversation up,
you have the chance to move it out of a straight commodity into
something special. This, would, of course, just be old wine marketing
in new media bottles.
Watson: internally, you need everyone marching to the same
beat. Whether it’s public or internal, you can use podcasts, blogs,
etc. to accomplish this. IBM is doing this.
How is Blogging Different…?
Moore: the mind-set of blogging always puts you in a mind-set of
“how can I be collaborating [linking & commenting] with this, or
find stuff to collab with?” He used to do the old xerox articles thing
to distribute, but now it’s the hyper-version of that. Ye Olde the
more links you make, the more links you get, aka, “the
information you get is equal to the information you give.”
Is Blogging Vocation or Avocation
Watson: it takes a lot of time to do it. PR people have been
managing the public image of a company for 50 years, spending a lot of
time doing it. And blogging will probably be the same: part of
someone’s job, not just “stolen” time.
Moore: I’m a one guy shop where people pay me for my ideas, so what
better place than a blog for that. But, you can’t go dark for very
long or people assume you’re gone and forget about you.
Bess: EDS’s started off as a group blog. “Definitely a way to get
diversity of perspective.” [Probably, just an easy way to keep the
frequency of a blog up instead of getting the One Post Bloggers.]
Q & A
Rubel: “How much to give away [on your blog] and how much to you
[keep to sell]?”
Moore: “The more you give the more you get.” But, I still “keep
some things in my back-pocket” to sell.
Rehling: we have a built-in audience enough that we can just give
away snippets of Mack Brown & Longhorn videos, and people will pay
“Wild Ducks”, or, Control
Watson: I thought I was one of the wild ducks, so I was surprised
when they asked me to blog. But, I’ve been able to hold back posts
like “Sun and Google Sittin’ in A Tree,” so there’s a degree of
self-editing that you need to have.
Moore: if we trust people in stores to do the right thing, why is
it different online. [Cause on-line, everyone in the world can
find and see it, while in stores, it’s isolated to the geography. This
is why investigative journalism exists: to get hidden camera video of
employees and companies wider exposure.]
Bess: we probably self-censor more that we should. My blog posts go
through corp. communications folks, and they haven’t censored anything
yet, so maybe we’re not pushing the envelope enough…
…as always, “don’t be stupid.”
Has IBM Ever Asked You to Blog About Something?
Watson: not yet, but I expect the day will come. “I’m partially,
whether I like it or not, a spokesman for the company…. To the credit of the communications people: no one has ever [censored] me.” And an exciting new phrase, “Have you heard about our Genetic Identity? Let me try to net it out.”
Bess: I’ve been asked, and I just do it if it’s interesting to
Rehling: In my industry, entertainment, we’re learning that we can make money from this.
Moore: blogs help small business look bigger, they can make them
Notes, or, “There was trouble at the
lab with the running and the exploding and the crying
when the monkeys stole the glasses off my head. Wh-ha ha.”
Dude, Moore is all into playing the mad-scientist role. He wears a
white lab-coat and flares open his eyes all the time and talks
Panel: Shel Israel, author of Naked Conversations; Ellen Simonetti,
author of Diary of a Flight Attendant and former Delta Airlines Flight
Attendant; John Slafsky, Partner, Wilson Sonsini. I didn’t catch the
Slafsky: Blogs are the Next Email for Lawyers
[Internal Blogging|External Blogging] Policies
Simonetti: Delta, of course, had no blogging or internet policy.
Slafsky: it’s, of course, good to come up with a policy, but, it’s
not going to be a cure-all. You can’t anticipate everything, so you
need abstract things.
Shel recalls an earlier quote from Slafsky: “you shouldn’t do
anything stupid.” And you’ve got the Scoble (from podcasts I’ve heard)
point that if you’re going to publicly blog about a company, make
sure you know the goals and culture of that company.
Controlling the Corporate Voice
Slafsky: “The short answer is that lawyers are cringing.”
Esp. those that work with/for public companies.
What Exec Has the Time for Blogging
Schwartz is cited as an example. Slafsky says that McNealy is
prohibited from blogging; his style of communicating doesn’t match.
When it comes to walking the delicate line of what to make public
and what to keep secret, Shel suggests that any C-level person already
knows that extremely well, so it’s not an issue of needing a lawyer
looking over their shoulder.
What Could Kryptonite Have Done Better?
Shel: The first company hit by bad blogging PR. A Kryptonite PR person
said they were working “around the clock” trying to figure out what to
do. There wasn’t an understanding, perhaps in anyone’s heard,
Kryptonite and otherwise, of what you’d do.
Blogger Arms Race
A MSFT PR fire-fighter said he used to have 10 days to respond to a
PR-crisis, but now he has 4 hours. There’s mention of using your own
bloggers to respond: a sort of blogger arms race.
How Could “The Bloggers” be Negatively Effected
Salfsy: the 1st amendment issues do a lot of shielding. But, there
will probably be some big liability cases very soon.