The Blogging Enterprise, 2005: Blogging To #1 – Positioning Your Company As The Thought Leader

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
Business, IBM.

(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.

Internal Marching-Vision

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
for more.

“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

Final Comments

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
get bigger.

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.”

Dr. John Frink

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

Tags: , , , , , .

The Blogging Enterprise, 2005: PR & Blogs – Anticipating & Managing The Blogstorm

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
moderator’s name.

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.

Tags: , , , , , .

Search Behind the Firewall, or, The Potential for the Information CMDB

…or, Lunch at The Blogging Enterprise 2005.

From talking with a table-mate from National Instruments, I came across the
idea that search is, and/or could become, something like a CMDB for
information in the enterprise:

  • Search can be the one-stop-shopping place for keeping up with
    info as it’s created, updated, and deleted. By caching and indexing
    all the information, you can accomplish the second thing…
  • If you’re looking around for something, you can search for
    it. The CMDB analogy being that, with a CMDB, you don’t have to go
    visit every single machine in your network to find all the XP boxes
    that need SP2 applied, you just ask the CMDB, ’cause it stored all
    that profile info.
  • If “actions”/macros are added to search results, and batches of
    search results, you can move towards a good
    approach to a compliance
    oriented architecture

Search Actions

That last point is where is gets exciting: what would make search
fully like a CMDB/Systems Management app would be if actions were
linked from your search results and you could take batch actions on
search results.

Tag & Bag Information, or, Regulation, Compliance, and CYA

For example, let’s say you need to retrieve all information related
to a patent lawsuit you’re involved in, for example, about JPEG. It
needs to be marked and bundled up to send to your lawyers. With a next
generation search app, you could write-up search queries like “JPEG or
JPG or ‘image file formats'”, etc. Then you could hook up an action
that would create a zip file with PDFs of each search result, to send
to lawyers.

Since it’d all be involved in a lawsuit, you’d want to assign ID’s
to each item so you could track them. So, your system could do
this. Even better, you could get a history of all the changes that
information had gone through, ’cause your search app had cached each
version of the doc, or, as CVS would do, the diffs between each
version. This would be analogous to versioning your configuration in a


By slapping RSS on top of search (creating RSS feeds from search
results), you can start to do mash-ups of behind-the-firewall
information. The top contenders are the “classic” examples of
distributing newsletter information to employees, thought leadership,
and statuses that you’d otherwise waste time in meetings

Ending the Intranet Ice-age

As I’ve noted
, all the services you take for granted on the internet —
Google, flickr,, bloglines, technorati — don’t exist. The
technology on typical intranets is effectively frozen in the late
90’s. What’s exciting about search behind the firewall is that it can
be the platform/beach head for providing all these features.

The Actions Are Endless

The patent CYA is a pretty simple example. But, you can imagine how
much you could do with your information once you normalize and cache
it into a central search repository: like I’m saying, it’s the
Information CMDB.

Lighting the Dark Information

Another interesting analog between a CMDB and search is that the application helps you get value out of what you already have. Also, it helps you stop loosing value from what you have. In the CMDB world, by imposing the regulations that come with that ITIL-mindset, you make IT more efficient and controlled, the goal being to let your IT group be less fire-fighter focused and more “how can we make money with all this IT” focused.

is, large companies have tons of information: silo’ed, “dark,” or
otherwise dead and lost. There’s money to be squeezed outta those stones, and search
is looking like a damn good juicer.

Tags: , , , , , .

The Blogging Enterprise, 2005: Kick-Starting The Blogging Enterprise Panel

Legal Stuff from John Slafsky

No law about blogs. So we’re trying to map existing law.

Things to Worry About

Trade secrets, product launches, roadmaps, revenue estimates,
defamation, employment law issues (getting fired for blogging),
copyright and patent law (like posting about Secure RSS), and
Securities regulation issues.

“People should not be blogging about the stock price, personal
matters, launch date of next release of product.”

On Blogging Policies

Probably not great as shields against liability. The blog author(s)
is still at risk[, as with all actions in a legalistic society.]

Todd Watson talk about Legal Issue with IBM Blogging

Engaging the legal freak-outers: they just need an explanation of
what’s happening.

Blogging guidelines.

Used a wiki to have internal conversations about the public
blogging strategy with legal, corp. communications, and the blogging


[What if turns out your blogging employees aren’t very good at
blogging? They don’t have domain knowledge, writing skills, or they
don’t have the “common sense” needed to know what to and what
not to blog.]

Using Blogs As Product Management Input. [The idea is that you’ve
flattened the input channels out so that you can drink from the
fire-hose of your customer’s comments. Assuming your customers have
enough passion about your stuff to spend time/energy to post.]

Q & A: Are Blogs Here to Stay?

Here to stay until the next things comes along. The business card
of the future. Here to stay. Train’s leaving the stations.

And here’s more detail from Shel.

Tags: , , , , .

The Blogging Enterprise, 2005: Steve Rubel

Here’s some brief notes from Steve Rubel‘s opening talk. Most of it was intro’ish stuff, so I just typed up the novel stuff:

Blogs can level the playing field for small companies — the
black-hole effect in marketing sphere — meaning that large companies
need to worry about them stealing attention. [And that large companies
can seem more like small companies.]

The old, CEO/execs can use a blog to get their message out instead
of being sound-bited. Mark Cuban was used, of course, as an example.

[Use your blog to promote and discuss the lifestyle/Godin-story your
company/product exists in.]

Shel Israel has a more detailed write-up.

Tags: , , , , .

Make the Iteration Fit the Deliverable, and Other Thoughts on Becoming Agile

I’m not sure I buy Cockburn’s machismo angle, in his
article “Are Iterations Hazardous to Your Project?”
, as the complete reason for the prevalence of 2 week iterations. As we’ll see, I think the underlying problem isn’t so much machismo as it is, well, not being wise enough to do otherwise as needed.

But I like his summary of why you’d want your iteration to be a
month instead of 1-2 weeks:

Usually, as I am witnessing it, the pressure that drives
teams to form pipelines is the machismo around short iterations. For
many teams, if they used an iteration length of one month, they could
jointly develop the requirements, database, code and tests for a set
of user stories all in one iteration, and then possibly even deploy it
and get feedback from their user base. However, they won’t set up a
one-month iteration, because then they will be viewed as sissies in
iteration-length bragging matches.

There’s a Lot of Work To Do

I’m interested in that middle sentence: in my experience, cramming
all those things into less than a month is difficult. I can see that
if you had an almost purely UI-centric, smallish application, and you knew
exactly what you were implementing, iterations of less than a month
wouldn’t be a problem. But when you’ve got lots of complicated,
undefined/unknown, non-user facing sub-systems that have to work
together, it gets difficult to come up with something demo’able —
running, tested features — that isn’t lame in less than a month.

To summarize my thinking: yes, if you know what you’ll be coding
and integration is easy, 2 weeks is great. The problem is that there’s
a whole lot more than coding and integration to do, and often-times
those activities are crammed into the 2 week iteration.

For example, you’ve got to: figure out what you’re supposed to
code; come up with designs and/or prototypes; figure out your testing
strategy; do your documentation, internal and external; put everything
together for the demo; and then do all the unexpected things that come
up, like figure out why the previous version of the product that
paying customers are using keeps shitting the bed.

Perfect Planning Doesn’t Happen

That’s all assuming that all your planning and story-carding is
done perfectly so that the everyone can hit the ground running. Of
course, that whole this planning and story-carding is often put into
the 2 week window as well. Defining
the problem sufficiently
to efficiently come up with the solution
takes a lot longer than we ever think, but we hardly ever give it
enough time. We’ll always “do it better” this time, as with all things

That is, it’s rare and difficult for an organization to achieve the
pipeline’ing that’s needed to effectively use two week iterations

Month Iterations are Training Wheels

What I’m saying is that most places probably aren’t mature enough
to do 2 week iterations. They’re not good enough at the process of
creating software to work that fast. Usually, the fact that they’re
adopting a new methodology indicates that how they’ve been doing
things wasn’t too functional in the first place.

As an indication of this lack of maturity, most people I talk with
take a sort of flippant attitude about Agile: “it means we don’t have
to do so much planning or documenting.” In fact, in my experience,
it’s the opposite, with a twist: you don’t have to do worthless
planning and documenting, you have to do thorough, but lean,
planning and documenting.

In my mind, if your going to be coding for two weeks, you’re
probably going to need 2 weeks for planning, designing, and all the
other project managing that 2 weeks of coding requires. Putting all
those activities into 2 weeks doesn’t seem like a good idea. And it
certainly seems to cause you commit the error that Cockburn warns
about: the end-result of your 2 week iteration isn’t
customer-deliverable. It needs more work before you’d think to give it
to an actual customer or user.

Dividing Up the Work is a Bad Idea

The temptation here is to get another group of people — product
managers or analysts — to do all that definition for the
development team. These people take the 2 weeks to write-up
everything. And then you have true waterfall pipelining. You end up
with a sort of process/methodology version of Conway’s Law:
the software development process and organization uses will directly
reflect the managerial and communication structure of that

The bad things about separating the roles out like this are:

  • Transferring that plan-think to the development team will be
    slow, error prone, and tedious. Ideally, the same group of people
    has defined things and, thus, no transfer is required.
  • With separate teams comes tribal thinking, that is, “us
    vs. them.” When software is created in this type of context, it’s
    much more difficult to write good software that users will love
    paying for.

(For more on the tribe problem, check out my
recent post on The Paradox of Scaling Responsibility
and this
anecodatal-ish discussion the problem
in the auto-industry)

Predicting the Future

Of course, you’ll end up having to re-plan a lot of stuff while
you’re coding it — that is one of the major epiphanies of
Agile-think, not that you don’t need to plan or document. This
suggests that you’ll want to spread out planning into your
coding. Indeed, you do. So, the idea of having 2 weeks for planning,
then 2 weeks of coding seems silly. Really, you need 4 weeks of doing
all that.

More importantly, as Cockburn says,

The length of an iteration is secondary in importance to completing
deployment-ready functionality. Replace your worrying about how short
you can make an iteration to worrying about how long it takes to move
from opening a new requirement until that requirement is integrated
into the deployment base with acceptance tests.

Point being, I’m not really attached to 2, 3, 4, or 6 weeks. I’m
more attached to the idea of clearly-enough defining your end-goal,
and then expanding your iteration to fit that goal.

A Theory on What to Do

If you find yourself in a situation like this, what I’d want are
two things:

  • Lengthen the iterations to a month to start with.
  • Make the “planning people” and anyone else working on the product
    part of the team (and I mean, really part of the team, not
    some half-ass just show up at meetings and take notes sort of
  • Make the roles in the team fluid: developers might do some
    planning, architects
    might do some coding
    , QA might write some code, planners might do
    some QA or coding.

As the team gets better at defining their goals and stories, you
can vary the iteration length as required to meet the customer
deliverable at the end of the iteration. But, as you’re learning, keep
things at a month to give the team time to learn how to better manage
the process of software development.

Being resistant to the idea that you’d have to learn this is where the machismo angle fits in, esp., as is commonly the case, if by “machismo” you mean “stupid” ;>

Ask “Is it Working?”

As with any process improvement, the most important thing is to
frequently and seriously ask if the changes are working. Using rapid
feedback to improve your efficiency and quality is, perhaps, the least
used tool in the Agile tool-box.

If there isn’t a constant stream of constructive-complaining from
the team, they’re either the best software team in existence, or
they’re hiding something from management. As the other side of that
coin: management should be constantly responding to that
constructive-complaining and seeking out ways to improve
things. Otherwise, they
just don’t get it

Granted, it takes a lot of professionalism on the team’s and
management’s part to even admit/think “maybe we’re not such
hot-shit. We should figure out what we do wrong and fix it.” I mean,
why would you get paid so much if you weren’t hot shit?

Of course, that question was answered
long ago

Charles and I have talked about the IUV article in one of our podcasts, Episode 23.

Tags: , , , .

Upfront Technical Planning and The Paradox of Scaling Responsibility

Most people’s #1 misunderstanding about Agile is that no planning
is ever done. You just get a list of story haiku (“the system must be
508 compliant, we have a contract” or “the system must interact 5,000
wing-dings, our customers demand it”) and start hacking away. More
importantly, Agile folks poop all over water-fall planning, and so it
seems that any sort of planning is “bad.”

Big Teams Aren’t So Agile

If you have one small team, this is somewhat OK: the team will
naturally do this planning as needed because they’ll take on full
responsibility to make sure things work. If planning is needed,
they’ll do planning. If prototyping is done, they’ll do that. A small
team that contains all responsibility for coding and project management
(as a canonical Scrum team does) can be trusted to Do The Right Thing,
as needed. So, you don’t have prescribe “first you must do all this
planning, then you do the design, then you code, then you QA.” The
small team will figure out what needs to be done and do it. They can
be Lean.

Software Development Tribalism

But once you have 5-10 inter-dependent teams, leaving out up-
front planning is an unhelpful mindset. Once you reach a certain
amount of people (10-20?), individuals begin to shrug off that
responsibility to Do The Right Thing as needed. They start to think
things like: “Someone else is doing that planning. And if problem
occur, well, it must be someone else’s responsibility to fix them.
I’ll just do my stories or tasks, and that’s it. What other power do I
have to do otherwise? I’m just one of 50 people!”

Paradoxically, by taking on an Agile approach, the organization has
caused individuals to take on a water-fall mindset.

There are two separate problems here:

  1. technical planning does need to happen in a multi-team
  2. as the number of people involved scales, due to the paradox at hand,
    each individual contributes less value to the project.

Stability Requires Planning

Stability is a good example of where upfront, technical planning is
needed. When it comes to multi-team efforts, my theory (as yet
unproven) is that you need to lock down a good (a.) API and (b.)
data/domain model before the dependent teams start. Things can be
added to those two, but you need a stable and “complete” code-base to
start with or the API and client teams will spend too much time
thrashing about what and how to implement things. That is, if you want
to move fast, when it comes to APIs and domain models, you really need
a benign dictator and not a committee.

Theories of the Fix

The second item is, of course, more vague and difficult to deal
with. So far I don’t have any solutions. The only thing I can think of
are the spider diagrams, and accompanying methodology for figuring out
how Agile you can be, in Cockburn’s Agile Software Development. That
is, all the people involved may not be skilled enough and/or of the
right work-mindset to be fully Agile.

There might also be something to the notion that more education
could help. If all the people involved haven’t received even the most
basic training or “thought-syncing,” it’s going to be difficult for
the process forces to execute correctly: people just won’t know what
they should be doing.

Tags: , , , .

Enterprise Tool Smells

Here at we are, of course, obsessed with Enterprise Software. So, e highly recommend and urge you to check out Ed Gibb’s funny (as in “funny because it’s true”) post on Enterprise [Software] Smells.

I think most dorks reading this have either (a.) experienced, or, (b.) written software that does each of the things in the list, such as my favorite one:

Support involves filing trouble tickets or issues that are never resolved though sometimes promised to be in the next release.

Tags: , , .

[ Podcast] Episode 27 – Carr and Streisand

Of this episode, Charles says:

The thing is, the analogy was in our minds, but we never paint the final stroke.

Which is, you hold what Barbara Streisand believes under scrutiny and use it to discredit all arguments from the left, and that is you cannot use a single article on wikipedia and use it to discredit the entire enterprise.

As always, we’d love to hear your comments.

Tags: , , .

Workplace for Business Strategy Execution?

IBM released an enterprise app called “Workplace for Business Strategy Execution,” or WBSE recently. It’s supposed to take corporate strategy, and break it out into tasks employees can use. And, of course, there’s dashboards so that “leaders” can keep track of progress on those tasks.

Here’s more from an article:

Users can take a business strategy, such as delivering a new product, and divide it up into a number of objectives. Each can then be assigned to a specific end user, or role, with a customized interface that displays the data that end user needs to execute and track their responsibilities within the overall project.

The WBSE interface includes four main concepts that are implemented using software from partners. Scorecards monitor not only overall progress for higher-level executives, but also overall progress per user/role within the overall strategy. A dashboard provides the individual user with relevant information on a day-to-day basis.

There’s also a snazzy video to go along with it. It’s a whole new way of business and computing! Make more workers more productive! IT does matter! Yay!

Agile Bid’ness

So, the big question is: what is this stuff?

From what I can tell (mostly from the video), the theory is something along the lines of applying Agile thought to business, and the software is a project management tool for managing that. So, you have “corporate strategy” (themes) that’re broken down into stories and tasks. The workers can see how their stories and tasks fit into the over-all themes, and everyone can track progress on those stories and tasks on dashboards. I mean, this is enterprise software: you gotta have dashboards, baby!

Good luck!

BSM for People

An earlier article from last month has an interesting take on WBSE, that it’s a sort of BSM/systems management for people:

The move is really an attempt by IBM to dumb-down performance management, which shares a similar goal of linking strategy to operational execution. Of course performance management is simply more than just rolling out a set of dashboards; the hard work goes on at the back-end. But what’s interesting about IBM’s BI dashboarding solution is the real-time linking of collaboration and other context-sensitive tools to drive real-time responses and actions based on objectives directly from business user desktops without having to get IT involved

The Single Pane of Glass

Also, check out one of my posts from May of this year for a vaguely related “shit you need to do today” thing with Greasemonkey. If anything, keeping a simple to do list in mind is a good point of reference for decoding the meaning of “Workplace for Business Strategy Execution” and other large phrases.

Tags: , , , , , , , , .

BSM and Heros Don’t Mix

David Norfolk sums up the problem with all systems management and BSM quite well:

Nevertheless, underlying all this BSM and SORM vision is an assumption that the parent organisation is reasonably mature — that it is committed to knowing or measuring what it has and how it is performing (for purposes of improvement, not blame), to documenting its goals, and to reducing the gap between reality and aspiration. This could be one of the reasons Gartner put CMDB maturity some 10 years out. If you work for the sort of company that values fire-fighting heroes and technical efficiency over effective business service delivery, attempts at implementing BSM or SORM may be doomed to failure.

Systems can measure, and even react, ’till they’re blue in the face, but in the end, it’ll always rely on people to do the right thing.

Tags: , , , , , .

[ Podcast] Episode 26 – Commodifying Enterprise Software, Standards by Monopoly

In this episode, we talk about The Paradox of Enterprise Software Innovation, how small companies can exploit their constraints to sell into the Enterprise Software market, and The Ambassador as an analog for technology monopolies.

Show-links: d&r_26.

Send us Comments!

As noted previously, we’d like to start splicing your audio comments into future episodes. If you’d like to comment, record the comment yourself, and email it to We’d prefer MP3s, but we’ll take whatever you can give us.

Tags: , , , .

Customer Therapist/Technical Spinmiester

In larger organizations — esp. in enterprise software — there are many people who play the dual role of Customer Therapist/Technical Spinmiester. This is a role that almost no organization wants to admit they need and have, but that every organization of large enough size has many, many people doing.

As we’ll find out, no one would want to admit that they have this role because the whole purpose of the role is to tell the customer “no” when it comes to fixing broken or otherwise screwed up things.

Cleaning the Bed

Obviously, I don’t have a perfect title for this role yet, but those those two titles capture the primary jobs of this role, in order:

  1. When your software shits the customer’s bed, you need to prevent them from going ape-shit and doing something like demanding a refund of all those millions of dollars they gave you.
  2. Control the spin of how the customer perceives your software. To a lesser extent, you want to control the spin of how the rest of the market perceives your software, but that’s usually only if news of the afore mentioned bed-shitting leaks.
  3. Containment: prevent whatever problems the customer is having from infecting the rest of your organization. For example, the customer could demand that you drop everything (like development of the next version of your product) and focuses exclusively on their problem. When someone’s holding a big wad of cash, this is always a huge risk. Another version of this is the dreaded mutual-assured-bundled-sale-descruction plan: “if you don’t fix these problems in product X, there’s no way I’m going to sign that multi-year/million dollar deal to buy products Y and Z!”

Software + Relationship

As many of you, dear readers, and I have spoken about face-to-face on several occasions, Enterprise Software deals are about half for the software, and half for the ongoing relationship that the vendor and the customer has. The customer wants to make sure the vendor will be there when things go pear-shaped. The role of Customer Therapist/Technical Spinmiester exists to take care of such times: they’re the relationship maintainers. The people who buy the flowers, give the massages, and promise “never to do that again.”

Small/micro-companies, of course, can’t compete on that level (despite being so God damn awesome): they don’t have the resources to provide an “enterprise-level relationship” with all their customers. (At least, it hasn’t been proven otherwise on a mass-scale yet.) Hence, the Enterprise Software Market is created and thrives where-in large companies sell software + relationship to other large companies.

As Charles and I start discussing in this week’s (upcoming) podcast, this constraint is something that small companies can use to drive features for their product(s)/services(s). But, you’ll have to wait until Friday for that.

Tags: , , , .

Going to The Blogging Enterprise 2005

Thanks to BMC (in particular, the VP of BMC Performance Manager, Israel Gat), I’ll be going to The Blogging Enterprise on Nov. 2nd, here in Austin.

It’s a day long event packed with several interesting speakers and panels, including fellow BMC’er Mike Smith, who owns/runs

And I’ll get a free copy of
Naked Conversations
to boot.

So, hopefully we’ll see and talk with some of you there ;>

Tags: , , , , .

More from the New Recruiting World

“Hey, how’s this for a short story?”

A few days back, I bookmarked an article about online job sites, like
(via Steve O’Grady). I’ve been interested in the hiring market since I scored a couple rounds of referral bonuses at work from want-ads. In addition to that, there’re several good quotes in the article:

  • On Monster suffering from the innovator’s dilemma: “Anytime companies get big, they innovate less.”
  • On the importance of referrals in the job process: “If you ask Americans how they found their current job 60 percent will say they got it through a network or a referral.”

Grass-roots Recruiting

As I’ve written in the past, I’m a big fan of what I call “grass-roots recruiting.” By that, (1.) I mean using your employees for sourcing when it comes to job leads by offering them referral fees, and, (2.) your employees re-posting the job on places like craigslist or linked in to get leads.

The company — H3 — profiled in this article has taken this to a meta-level, cross company:

“They produced very bad quality candidates,” Gieskes says of Refer, “because they allowed any stranger to put forward names of people to try to get a reward.”

With H3, he says, “in order to refer someone, you have to be approached by someone who knows you,” and who sends you an e-mail first about the job. If there’s a $3,000 bounty, for example, and you pass the e-mail along to someone who gets hired, you keep the three grand. If you pass it to a friend, who sends it to another friend, who sends it to someone who lands the gig, the three referrers each get $1,000. H3 demands a 10 percent fee, paid by the employer, on top of every bounty that successfully fills a cubicle.

Now, so far I haven’t been too big a fan of all the social network things out there: they never seem to do quite enough once I finally get all The Usual Suspects to create YetAnotherProfile, we can rarely figure out what to do next.

I’m not quite sure if H3 will cook the biscuits, but it looks promising: once you start handing 1,000’s of dollars out to your users, you’re onto something.

Tags: , , , , , .

[ Podcast] Episode 24 – Small Businesses, Agile planning & Estimation, and Happy Endings

In this episode, we talk about the paper-work behind starting a small business, getting better at planning and estimation in software development, and have some choice comments on the XP take on the theory of user stories (be sure to listen past the Liquid Labs promo for that).

(This episode edited by Charles.)

Tags: , , , , , .

[ Podcast] The IUV Triplet, The Hati Point, and Empirical Project Managemen

In this episode, we talk about Cockburn’s “Are Iterations
Hazardous to Your Project?”
article, Agile-think re: scaling
projects from 5-50 people, and figuring out what we want from the

Also, starting with this episode, I’m trying out listing all links to stuff we talk about on with the tag d&r_23, as in “Links for Podcast Episode 23.”. My thinking is that for each episode, I’ll create a new tag, e.g., for episode 24, d&r_24.

Also, see the post about the for_d&r tag.

(This episode edited by Coté.)

Tags: , , , .