Trampoline Systems

* Trampoline Description Here

Trampoline Systems

* Trampoline Description Here


Content

Humans

Trampoline on Trampoline, enterprise social computing, user experience and organisational trends.

Archive for April, 2008

peter

Companies are for-profit Communities

By Peter Biddle on April 30th, 2008

I’ve seen a few comments on blogs about the intersection of social networking and business which questions the idea that an enterprise is a social network at all. Some have simply made the assertion that social networks and businesses are totally different - eg on the SONAR tech-crunch posting, Phil Dewey commented: “Does “enterprise social network” = social networking for a******s? Seems like “enterprise” and “social” are mutually exclusive…”

Companies are for-profit communities, and as such share many, if not all, of the characteristics we associate with any other type of community. Enterprises are most certainly social.

rebecca

No Man is an Island, John Donne (1624) and enterprise social computing, Trampoline Systems (2008)

By Rebecca Kemp on April 23rd, 2008

Rarely is one presented with a delicious opportunity to delve into the connections between stickers produced last week, a metaphysical poet from the early 17th Century and the concerns of enterprise social computing. Trampoline is the only workplace on earth I can imagine that occurring. An unhealthy obsession with correct spelling aside, this is the first time I have used my English degree in my career. You have been warned.

Let’s begin with stickers. Trampoline has a batch of them, rapidly depleting and strewn between London, Seattle and San Francisco; a gingerbread trail for wandering Tramponauts. They’ll mostly be encountered at Web 2.0 Expo San Francisco this week. Find them and us at booth 629 where we’re being kindly hosted by Oracle. Perhaps you already have, and that’s why you’re here. In which case, make yourself at home.

We had to put something on our stickers. Various ideas were batted around, particularly single words relating to our technology and the world of enterprise social computing. Not bad, but nothing that would achieve our main aim of people liking or identifying with the stickers enough to put one on their laptop. In a flash of inspiration, spurred on by copious cups of tea, I remembered the phrase “no man is an island”. We went with it and a mutated version of our logo.

I was prompted to look at the origins of the phrase and found it belonged to John Donne, a favourite of mine in my late teens. (Don’t laugh, I just love poems.) Here’s the text:

No man is an island entire of itself; every man
is a piece of the continent, a part of the main;
if a clod be washed away by the sea, Europe
is the less, as well as if a promontory were, as
well as any manner of thy friends or of thine
own were; any man’s death diminishes me,
because I am involved in mankind.
And therefore never send to know for whom
the bell tolls; it tolls for thee.

Or, as Donne himself had it, and as I prefer:

No man is an Iland, intire of itselfe; every man
is a peece of the Continent, a part of the maine;
if a Clod bee washed away by the Sea, Europe
is the lesse, as well as if a Promontorie were, as
well as if a Manor of thy friends or of thine
owne were; any mans death diminishes me,
because I am involved in Mankinde;
And therefore never send to know for whom
the bell tolls; It tolls for thee.

In essence, every time a man dies, I am affected. Or, to turn it on its head: a group of men is something bigger than the constituent men are as individuals. Together, they are bonded, collective, and the loss of one is a loss of and to all. The text was originally prose, Meditation XVII: Devotions upon Emergent Occasions and IMNSHO this is far from Donne’s best verse. I was tickled by the occurrence of the word Emergent though. At Trampoline we often consider about the ways our technology can support and even identify emerging communities of interest. By this point, I was convinced Donne’s few lines had a good handle on what we’re trying to do at Trampoline, and why we’re doing it.

We believe that people aren’t alone at work. And if they are, they shouldn’t be. Groups and organisations succeed by being greater than the sum of their parts. The constituent parts need to work together to succeed. In Trampoline’s area of practice, large enterprises, that logic means that organisations should be encouraging people to work together, connect, collaborate and tap into each other’s knowledge. This often takes the form of giving people tools, perhaps software. In bringing people together to collaborate, you allow them to create something that wasn’t there before and couldn’t have existed without the fusing of their knowledge and ideas. This is particularly relevant to organisations full of knowledge workers whose main resource is in their employees’ heads, or organisations striving to succeed through innovation. Bunches of individuals working as hard as they can can’t produce new ideas and move them forward like groups of people working together can. We’re all in it together.

So there you have it: John Donne to Trampoline Systems, with stickers as my conceit. I’ll leave you to learn more about what Trampoline does and what Donne did. I recommend the ones about intelligent social networking for enterprises and persuading a lady into bed by ranting about fleas. The choice is yours.

peter

Trampoline and the economy

By Peter Biddle on April 14th, 2008

It’s super important that we think about how Trampoline should act in a flat or recessionary economy.

From this http://blog.hbs.edu/faculty/amcafee/index.php/faculty_amcafee_v3/recession_tech/ posting:

“Third and finally, as business slows down workers often have more slack in their weeks. When this is the case it’s easier for them to find time and energy to participate in Enterprise 2.0. So lean economic times might be the right times to launch an effort to build an emergent social software platform.”

Recessions are most likely to bring MORE work for fewer IT people, not less. So let’s think about how a recession could affect us.

It departments have been under the efficiency grinder for quite awhile now. The days of bored IT people sitting around doing nothing are well over. After the inevitable fat is trimmed, usually some meat gets lost as well, and so some departments, unhappy that they now have to wait around for 3 days to get email turned back on by IT, will staff up with a few folks who manage mundane things like printers not working, etc. In some cases these people have so much work that they grow to resemble small IT organizations unto themselves. These people may be contractors or full timers.

Whereas in the past, IT might resent this intrusion into their domain, they may well actually like these guys now because it means that someone other than IT sucks up first-line issues that the It department essentially gets credit for. In other words, the “efficiencies” that exec management forced onto IT after the dot-com bubble burst seem to be working because the accounting system doesn’t count people in departments as “IT”. So like magic, fewer people seem to be doing more work.

Now comes a recession and real downsizing. There are a few ways of cutting staff - I’ll focus on 3: Peanut buttering, early retirement, and targeted re-structuring.

Peanut-buttering is the most common, unfortunately. In this model, every group is given a target - say an 8% reduction. Every department gets to do this however they want. A bell curve of competence means that at least half the company will do this poorly, unfortunately, so it can appear to be completely random. Even when done right, it’s not perfect because it’s hard to say how this supports overall strategic imperatives. Hopefully the first people to get cut here by will be “overhead”, meaning contractors (easy to lose) and people who aren’t part of a core business, like the co-located, non-IT, IT people above. (In the good old 90s you could get away with cutting FTE and then immediately replace them with contractors, often paying more for the same people you just downsized, because accounting tricks let you do this. I don’t think that this happens much anymore.)

So first off, there’s an issue of downsizing of departmental (co-located) IT staff, which reduces the overall capacity of the entire company to manage IT. This immediately means MORE work for IT, not less. IT won’t be given more staff, of course, because the rest of the company is belt-tightening, there’s no way that IT can get more people. So with departments now completely beholden to IT again, there’s more work heading into IT.

Then comes staff reductions through early retirement or cutting off low performers. In both cases those people are encouraged to quit through a variety of means. For IT, off-boarding requires IT work more, just like on-boarding does. Accounts must be deleted, physical assets tracked, documents archived, etc. So, more work for IT. Oh, and in these cases it’s rare that the actual HIRING slows down significantly because no company wants to be in a position where, when the recession is over, the best and brightest all work somewhere else. So again, more work for IT.

In targeted re-structuring (IMUNVHO the best way of managing this) the exec staff make a decision about what the most important bets are for the c
ompany, and then they a) move the very best 5-10% of people in any group not working on these things to the important bets (meaning that, even in a recession, the big bets get an increase in funding!), and then cut the living crap out of other groups. Hopefully in some cases this means getting out of businesses altogether.

All this means, you guessed it, more work for IT.

What does this mean for us?

Easier technology is certainly better. Going with a VM-based solution is a good plan and gets better here, provided of course that we can get the perf we need. We will do our own SONAR installs on VMs from now on to prove to ourselves that they work and so we are dogfooding.

Why full VMs and not just the JVM? While much bigger, fatter and somewhat slower than systems with less abstraction, full VM’s are also the most portable solution, so if things change departmentally underneath us, then a VM is our best bet for picking a server up and moving it somewhere else. They also mean that we don’t have to care about things like the underlying OS or hardware as much. Every enterprise kinda sorta looks the same at least for this part of the stack. We can dogfood our solutions essentially the same as our customers much more easily.

Clearly we have some selling opptys that “old school” SW may not have. We should focus on empowering besieged employees to do more with less and to enjoy their jobs more. Another selling oppty will be linking into CRM and the sales pipeline - the best time to steal customers from your competitors is when they are facing downsizing, so talking about how we make that work, and how we make defending existing customers work, is very good.

IT will have to start cutting into some projects. I think that big, “re-do the entire enterprise so it sucks less” things will get postponed. After all the company has found a way to do what they do with the existing suckage, so they can assume they can afford to wait. Low-risk new projects are going to be higher pri than high-risk, as no one wants to be called up for breaking something critical in a down economy. Not fun. So our “stay out of the way of critical infrastructure” architecture is important.

Our heterogeneity is critical, as companies with more than one architecture will wait out homogenizing things. We hear that people are planning on deploying things like SharePoint and Exchange, but any wholesale move to just MSFT or any one company should be years out, at best. And our ability to easily integrate new data sources means that we can just say “bring it on” whenever a customer comes up with a new plan for a wiki, blogs, IM or something else.

Also we don’t require massive work to get up and running, in spite of the bumps and bruises we are involved in right now with pilots. We aren’t spreading the work out around the entire enterprise and we don’t require massive training. Frankly we’re pretty painless compared to something like a CRM system which involves lots of hand-wringing and holding and which inserts something into a business process, making its failure far more risky.

Lastly, we have a lot of flexibility in how and when we monetize, which is very good, and we aren’t reliant on the overall health of third parties (eg advertisers) to make money. It would suck to be totally beholden on both our enterprise customers and also an entirely separate segment of the economy.

All in all, I think our pluckiness and positioning should serve us well, even when things are a bit hairier as budgets disappear and people don’t return calls because they are busy dealing with the latest crisis.