A real corporate meeting, avoiding triggering The Boss

This anecdote from a story on Sears struggles is spot on strategic thinking for most corporate meeting:

There, two mid-level employees were preparing a presentation for the CEO, Eddie Lampert, when their boss rushed in with some last-minute advice.

On a chart pad he wrote three words.

“He looks at the presenters and says, ‘Do not say these words to that guy,'” according to a former Sears executive who described the meeting to Business Insider. “That guy” meant Lampert, who would soon appear on a giant projector screen at the front of the room, beamed in live from a home office inside a $38 million Florida estate – 1,400 miles away from headquarters.

The pad with the three words was out of sight of Lampert’s video feed. One of the words on it was “consumer.”

The stakes were high. If any of those words were uttered in front of Lampert, the two presenters would “get shredded” by the CEO, whose frequent tirades had fostered a climate of fear among the company’s most senior managers, said another person – this one a former vice president.

These two and other executives say “consumer” can trigger Lampert. He wants employees to instead refer to shoppers as “members,” which is his term for customers who are enrolled in Sears’ Shop Your Way rewards program.

It was at that moment, as the executive attending the meeting watched fellow employees anxiously censor themselves in front of Lampert, that he realized he needed to flee the sinking 123-year-old company.

That perfectly captures how much energy you need to spend on seemingly ridiculous details to be successful in corporate environments, not only in caustic ones, but pretty functional ones as well. I love chronically this type of tacit corporate knowledge.

The rest of the article is great background on how older companies are struggling to modernize with plenty of anonymized sources telling gritty, but helpful stories.

Business people need to understand how software development works

This led middle managers to over promise and under deliver. One middle manager told us that “you can get resources by promising something earlier, or promising a lot. It’s sales work.” This was made worse by the lack of technical competence among top managers, which influenced how they could assess technological limitations during goal setting.

As one middle manager pointed out to us, at Apple the top managers are engineers. “We make everything into a business case and use figures to prove what’s good, whereas Apple is engineer-driven.” Top managers acknowledged to us that “there was no real software competence in the top management team”.

Who knows if that notion about Apple is true or if it causes their success. The broader point of needing to understand the unpredictable nature of software is still important. As more organizations start using and making custom written software (if only to make mobile “store fronts” to their business), knowledge of the chaotic nature of software development needs to spread more beyond IT. Even IT people get it dreadfully wrong often.

So far the best tactic we have is to redefine what “success is”: it’s not delivering everything you promised on time, but being predictable about delivering something on regular intervals. That’s a vague way of saying delivering smaller batches of code into production more often. We sort of predict/hope that this results in more useful, better software overall. We’ll see.

Now, of course, part of this process is being honest about reality. The analysis of Nokia’s failures because “management” would not accept “real talk” from their employees will kill any innovation-driven business. As the company (and RIM and countless others) shows: tech companies are never so secure that they can afford to be confident in their market position.

More on GigaOm’s demise from the former head of the analyst side of the house

Commentary on GigaOm shutting own from the analyst/research perspective:

We thought, what if we could provide a platform for some of these independents to reach a wider audience through a research service from Gigaom? We believed that if we could pay these independents to write reports on a freelance basis, they would get the exposure of being part of a ‘virtual analyst network’ at Gigaom and we would get to tap into their expertise without having to pay the high salaries that often come with such knowledge and backgrounds. Win-win.

Including pricing, an aspect of the analyst business that I think will is key, esp. for new ventures there

We made a decision to launch at what seemed to many a ridiculously low price of $79 per year. But because we were doing something that we believe had largely never been done before, we were trying to gain significant conversion of our readership — probably around 2–3 million monthly uniques at the time — to the research product. We thought if we could make the price so low, it would enable the ‘true fans’ of Gigaom to subscribe and support while providing immense value in the form of research.

Also, this on revenue estimates:

Over time, increasing the sales and marketing mix towards research did make sense. According to an interview made by Paul, he said that research made up 60% of the company’s revenue. In the same article, revenue were estimated to be $15 million, so that translates to about a $9 million research business.

Anyhow, if you like the inside baseball of analyzing the analysts, this one’s got some.

More on GigaOm’s closing

Well, this is a problem:

But Gigaom’s research business had actually become a significant drag on the company. While it had started out as a “pro” subscription business charging individuals as much as $299 a year, after a couple of pivots, the company’s research arm was now focused on creating custom whitepapers and other products, like Webinars, for corporate clients. While that group booked $8 million in business last year, it wasn’t profitable. That was partly due to high sales and product costs and but also because some of that $8 million never materialized as the company didn’t create the work it was supposed to.

As reported in one of the more in-depth pieces in GigaOm over at re/code.

The decline of Novell

I’ve been reading up on Novell’s history. So far it’s got some fascinating twists and turns. Wikipedia sums up the turning point well:

The inclusion of networking as a core system component in all mainstream PC operating systems after 1995 led to a steep decline in Novell’s market share.

That is, once networking become “commoditized,” the unique position Novell had with IPX changed. And then there’s some channel hijinks that happened.

I’m also obsessed with figuring out what went wrong at Sun in the 2000s – Novell seems like some good mental training wheels for that.

The decline of Novell

One of SAP’s first SaaS attempts shifting around

While some reports had that SAP’s Business ByDesign was being slowly shut-down, the Enterprise Irregulars list pointed out a Tweet from Vishal Sikka that it was more of a transition, one that will ROCK no less.

Whatever the case, and perhaps this is all rumors as well, here’s a good chunk of info from the original piece in Wirtschaftswoche (I don’t read German, so I’m just going off the Reuters story):

The magazine reported, however, that the product, which cost roughly 3 billion euros to develop, currently has only 785 customers and is expected to generate no more than 23 million euros in sales this year.

I like keeping up with these early cloud build-outs – it’s good foder for figuring out how large, incumbent tech companies do with updating their portfolios. Back at RedMonk James covered ByD pretty closely, here’s a piece from 2009. It seems like a really good way to go down-market. As I recall, there was a lot of in-housing of the technologies, which has always been SAP’s, well, “thing.” And the fact that they’re moving it to HANA is more of that. NIH doesn’t portend failure at all: Google is rife with NIH, building its own platforms and such.

The bigger thing to pay attention to is (a.) enterprise software vendors need SaaS versions, or at least versions that will take advantage of private cloud technologies to ease management and cost control, and, (b.) making a SaaS that’s “enterprise grade” is hard.

One of SAP’s first SaaS attempts shifting around