Blog

Trampoline and the economy

By peter | Monday, 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.

This entry was posted on Monday, April 14th, 2008 at 10:35 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.