The IT Skeptic - Comments for "Cloud is a distraction to IT's day job"

Spot on Peter (and hope

Rich Pemberton — Mon, 23 Jan 2012 14:39:43 +0000

Spot on Peter (and hope you're well, my friend).

Reading this post again made me wonder if the reason for the fuss about the cloud is less about true innovation - it's not exactly a new idea anyway, is it - and more that it appeals to business leaders fed up with having to deal with IT that demands to be visible. And in this context Skep is absolutely right to focus on the 99% (or whatever) who 'keep the lights on'.

In my view it's not about 'IT as a utility' per se, although elements such as storage and processing power are already becoming commoditised, but I suspect it is seen more as buying a business outcome that IT has traditionally not delivered upon.

It is a touch of the emperor's clothes of course, ITSM has just as much importance as Peter says, more governance-focused than operations, but we'd do well to understand the Cloud's popularity in the context of Ian Clayton's 'Outside-In' mantra: is it that the remote Cloud suppliers speak to the longings of the Cs who just want stuff to work without the fuss?

drudgery

skeptic — Fri, 09 Sep 2011 11:12:23 +0000

You are correct that the "stay out of IT" was an exaggeration. However I don't think you will dispute that there is more innovation going on at Google. That said, I'm betting the vast majority of Google employees have non-innovative jobs.

I dispute that life is a simple choice of innovation or drudgery. Jobs can be challenging, rewarding and even creative without necessarily being innovative.

In house IT does need to innovate

Charles T. Betz — Thu, 08 Sep 2011 15:16:56 +0000

I was responding in particular to the following statements:

You: "if you want to be an innovator, stay at MIT, dont go into IT. Get a job at Google, not some insurance company in Omaha."

Stanislaw: "anyone who wants to do research and development should stay out of Information Technology."

These are global statements that seem to say that 0%, not 5% of IT staff might find themselves doing innovation. I beg to differ. Even for the Omaha insurance company.

I'm also reminded of Turing's immortal quote on computing:

"as soon as any technique becomes at all stereotyped it becomes possible to devise a set of instruction tables which will enable the electronic computer to do it for itself."

This inexorable truth is the harsh reality for those who might, on your advice, resign themselves to a life of working in "non-innovative" roles. Why accept that when such roles are destined for the automation hopper?

Charles T. Betz
http://www.erp4it.com

Stop promising innovation to everyone

skeptic — Thu, 08 Sep 2011 01:18:21 +0000

I don't think this contradicts my point at all. IT as a whole, as a black box, needs to measure its value in terms of innovation delivered, sure. That is an important measure, and it is of increasing importance as the pace of the world increases.

But...

1) that doesn't mean IT has to stop measuring itself in terms of value for money, and in terms of protection and stewardship of existing assets.

2) just because It as a whole needs to be increasingly innovative doesn't change the fact that 60% of us are there to protect and manage the existing systems, and 35% of us are there to create designed solutions. it is the job of the other 5% to identify innovative new directions, evaluate their potential, and input innovation to the other 95% as proposals.

Telling everyone in IT that they need to innovate is
(a) a distraction from their day job
(b) a source of dissatisfaction due to the cognitive dissonance of having to deliver on other measures of value and risk.

Innovation is exciting, creative and cool. People who get to work on it are so lucky. Actually they're not lucky, they're talented. Stop promising it to everyone - you just screw the place up.

Another take on innovation in IT

Charles T. Betz — Wed, 07 Sep 2011 17:51:33 +0000

Some real data on innovation in IT is here:

http://i.techweb.com/networkcomputing/private-cloud/B2850511_Usage_Based...

It contradicts many of the assertions in this thread. IT as a source of product innovation is increasing at least in some quarters.

Charles T. Betz
http://www.erp4it.com

Cross-rotation

Peter Suba — Sun, 04 Sep 2011 00:23:59 +0000

Skeptic, just to clear the misunderstanding - I am not saying cross-rotation works well either. I would try 10-15 different things before this. What I tried to explain is why, if someone does it, makes sense.

I personally think that while you can make it work, the return on that investment (i.e. giving up the time from doing the work they are good at) is much smaller than a lot of other solutions.
But there IS a return on that investment.

I personally don't even think ops should be equal to dev. Or more rights. Or less. I think they are so different and at the same time both needed (not necessarily in every org, but in most big ones certainly) that I just don't see how you can start the comparison. It is misleading. You need proper governance and management above both functions to make sure they work well and deliver according to the organisation's priorities.

rapport

skeptic — Sat, 03 Sep 2011 19:48:17 +0000

Peter, your first few paragraphs are one of the best expositions of the "tension" between dev and ops I have seen in a while. And I agree - to an extent - about the solution. I don't think rotating dev and ops jobs works so well, per se. They are - as Morgan points out - differently skilled. Communication and rapport between the groups is the key, as I espouse in Dead Cat Syndrome. And I lay the responsibility for making it happen at Ops' door.

Ops will find the task easier if senior management encourage a cultural attitude that dev and ops are equal peers, instead of the common idea that ops are the menial lackies of the brilliant and creative developers, obstructive bureaucrats stifling development's art. ITSM doesn't assert superiority of ops, it just demands equal rights.

Dev in Ops

Peter Suba — Sat, 03 Sep 2011 11:59:20 +0000

I am trying to find the main point you are trying to make and pick up that thread only. I apologise if I mistook it for something else.
Which I think is about dev in ops.

Fundamentally, yes the attitude in the "dev" world tends to be markedly different from the "ops" world.

People in "ops" are asked to deliver stability, value for money and their performance is measured against this.
People in "dev" are asked to delvier something new, with low cost and quickly - and likewise, they are measured against this.

There is a natural tension in this all between the two worlds. If in your development you cater for the requirement of monitoring, debugging, recovery methods, high availability mechanisms etc, that all costs money and takes time - and does not add to the "something new", the core reason the business asks development to get involved. So from their perspective they will want to do as little of it as they can get away with. This is normal. On the other hand, you have someone coming along and introduce something you are not sure about, upsetting the key metrics you are actually measured against. No wonder this drives tensions between the two worlds. Not to mention that budget is usually not in one hand so both sides expect the other to cover the cost of accomodating their needs.

The only question is what can you do to balance the need between new functionality and stability.
You can create acceptance criteria and corresponding checklists. Acceptance criteria is coming from Ops to say "this is what we need you to fulfill so we can accept it in production". (Different organisations have different tolerance thresholds on HOW MUCH of the checklist can be unfulfilled while management decides that it is "good enough" to go, but that is a different discussion).

So how do you get Dev to accept that they have to work against that checklist? Because of course by default (see above) the dev team will see this as a waste of their time and they want to concentrate on delivering the core functionality. You can decide that the only thing you do is be very strict as an organisation and keep rejecting a go-live until the dev team fulfills all criteria. The problem with this is that it is very costly and takes a lot of time. How much better would it be if the dev team would just accept that they need to design the operations requirements straight from the beginning (and deliver proper testing and documentation etc)? This is where you may decide to cross-rotate teams.
You cross-rotate ops to dev so they can set their criteria in the knowledge of what goes on in the dev world - for example they specify it is a format which can be taken up in early stages of requirements analysis. You also cross-rotate dev to ops so they have more appreciation that what they develop is not needless. Dev representatives often talk to the business users and they get the feeling that what they are working on will be used. They should get the same feeling about the work they put in to help ops.

Cross-rotating (for me) or involvement in each others tasks is not about lack of need for a division between the two world. It is to make the transition smoother. Like skeptic, I do not believe that simply putting an ops person in the dev world (or vica vera) they would immediately do a good job (given time they could of course learn). This is normal. But having a healthy level of knowledge about each other helps work together with less amount of negative feeling about each other and ultimately it will make both sides work easier.

Fine then, differently skilled

L. Morgan Stanislaw — Sat, 03 Sep 2011 11:05:54 +0000

Then reread with "more highly skilled" as "differently skilled." And if they are only differently skilled but not better, why the need to put differently skilled persons in their place? What does this need have to do with service management?

I find your comments telling.

You would think that someone advocating a service orientation would exemplify the virtues of the customer service staff: endlessly patient, welcoming, poised, non-judgmental, focused on solving problems, eager to guide customers to a solution and unwilling to seize on inessential matters.

But what do we see instead? A pronounced resentment toward so-called "hackers" and a meanness of tone suggesting schadenfreude toward displaced workers--specifically, those you are working to displace. Why do you enjoy putting "hackers" in their place? How does this exemplify the ideals of service management?

In my own case, I happen to be extremely patient under pressure and utterly fearless in the face of complexity. I don't feel as though customer service work is the best use of my time, but on the occasions when I have been called to do it, I have been extraordinarily patient. People say that I persist and that they would have given up in frustration long before I do. I once was relied upon during service outages for those reasons.

The attitude that would lead to a desire to put workers in their place can fairly be called disgusting. But I understand why you would blame hackers for perceived resentment to ITSM: it is more convenient to place the blame elsewhere, than to accept responsibility for at least some of it. This is a behavioral issue. And service management begins with behavior.

According to the ideals of service management, pointing out bad behavior is not as helpful as indicating the desired behavior. I want to be helpful. Therefore, I will rewrite your remarks according to the ideals of service management to help you improve your future behavior.

"In my experience, developers and operators are differently skilled. There is no empirical evidence to suggest educational or cognitive differences between developers and operators. They both undergo the same levels of training, and the very best work to improve by consciously staying out of the autonomous stage of learning, in equal numbers among developers and operators. Operators excel at problem solving under crises, have excellent customer service skills and thrive on having their priorities changed. Developers operate on what Paul Graham calls the makers schedule: it takes them at least half a day of sustained effort to make progress, and they are more sensitive to interruption."

skills

skeptic — Fri, 02 Sep 2011 23:52:01 +0000

"more highly skilled workers are recruited to do less skilled work" And people call me bigoted. What makes you think dev are more highly skilled than Ops? Most developers I've met wouldn't make a good service desk analyst's a... ...ssistant.

And watching vendors' super-techs under the blowtorch of a critical sev 1 outage is often revealing. They may be able to build pretty software but supporting it under pressure requires an entirely different set of skills. Not less or more, just different.

I reckon a lot of the resentment towards ITSM is that yesterday's prima donnas - the hackers - suddenly find themselves put in their place.

Right: I wasn't quoting you.

L. Morgan Stanislaw — Fri, 02 Sep 2011 22:36:59 +0000

It does not follow from what was quoted that you did say it, and I was aware that someone else said it. Noted.

I was pointing out a few things.

One: someone said it on this blog. That's already an indication that the attitude is not uncommon.

Two: the attitude that no one is above ops isn't specific to that comment. Funny how it works out in these quasi-communistic schemes (there's an inflammatory phrase for you!) that more highly skilled workers are recruited to do less skilled work, and never the other way around. But again, I don't believe that any justification is forthcoming or that it would be interesting if it were.

Three: the questions about key performance indicators were really rhetorical. I have no expectation that they would be answered or taken seriously.

I think your 95% figure is probably correct, and may be generous. And I see that you have been saying this for some time. Some of us have taken a vow of poverty to go into R&D. But that reflects an economic reality: IT departments are increasingly adopting a service orientation. I think there is a tension between high-performance computing (HPC) and IT as ITSM. Why do I say this? One reason is that the directors of federally funded research computing centers have told me, point blank: "HPC has to be kept separate from IT." Also, I have seen HPC and research computing facilities evaporate when they were consolidated with IT, especially under managers who favor ITSM or one of its derivatives. This is not an isolated phenomenon. The mindset that you keep the lights on, and the mindset that you get involved with Edison's invention of the light bulb are different. HPC has some of the latter. When it ends up under IT, it tends to suffer, because--and this is my experience--the kind of one-off development normative and necessary in research is frowned upon in IT.

devs in Ops

skeptic — Fri, 02 Sep 2011 20:34:13 +0000

If you look closely you will note I didn't write that comment.

The idea of "devs in Ops" is amusing. It would be like those TV series about city-girl bimbos sent to work on a farm.

I'm sure it happens in tiny wee Agile teams but its rare in the real world

I read it on this blog

L. Morgan Stanislaw — Fri, 02 Sep 2011 16:56:00 +0000

"I am all for devs carrying pagers, performing L3 support, triaging critical incidents, and rotating through ops team, because it's the only way for them to learn how to write production-ready software."

URL: http://www.itskeptic.org/devops-and-traditional-itsm-why-devops-wont-cha...

The only way for [developers] "...to learn how to write production-ready software"? Citations and key performance indicators to that effect, please.

developers on the service desk?

skeptic — Fri, 02 Sep 2011 10:17:00 +0000

If you register for the site I think you might get to edit your own comments :)

Developers don't innovate. Cutting code is not innovation. Designing systems and services is rarely innovation. True innovation is often implemented by external consultant experts.

So yes, if you want to be an innovator, stay at MIT, dont go into IT. Get a job at Google, not some insurance company in Omaha. Hey even at Google, how many of their staff do you think can call themselves innovators?

Only the top 5% get innovator's jobs so study hard kids.

And in all my years I have never ever seen a developer rotated onto a service desk.

Disgraceful

L. Morgan Stanislaw — Fri, 02 Sep 2011 08:33:53 +0000

I must correct typos, and then bow out--I have exhausted the subject. I see you have addressed these issues elsewhere on your site.

"...students should be aware that the jobs they [thought] they were preparing for no longer exist as such."

"... as if their IQs are at least as low as their managers may be unassailable..."

These humiliating errors, which expose to the Internet a mind clouded by tenebrous vapors, have completely undermined whatever shred of credibility I might have mustered.

Back to Nifelheim!

Fair enough

L. Morgan Stanislaw — Fri, 02 Sep 2011 07:56:26 +0000

The conclusion then is that anyone who wants to do research and development should stay out of Information Technology. Based on my experience, that sounds like sage advice.

Educators are obligated to inform students about their employment prospects. If students study computer science and want to become software developers, they should be aware of the growing perception of information technology as a service profession. This has to be spelled out. Developers will be rotated into the help desk. Their future managers will have various rationalizations prepared--the point is that whatever those rationalizations are, students should be aware that the jobs they throught they were preparing for no longer exist as such. If you don't want to be on call, or if concentrating on software development for hours at a time is what drove you to become a software developer, some manager who knows better is going to see to it that your train of thought is interrupted, early and often. The reasons given for rotating all staff to the help desk or for instituting compulsory re-education camp attendance or treating staff as if their IQs are at least as low than their managers may be unassailable--that's not the issue. Those reasons would not be interesting even if they were forthcoming. The issue is ensuring that students and prospective employees make informed career decisions.

On that basis, my advice to students would be to stay out of information technology.

get real

skeptic — Fri, 02 Sep 2011 04:07:37 +0000

Oh... crap. People who seriously suggest computing will one day be as simple as electricity are hard of thinking.

Every kWh is like every other. your data is your data. Mine is mine. Computing will never ever ever be a commodity utility in the same way that electricity or water are. Get real. Computing will always be the entrusting of one of your most valuable corporate assets to someone else.

stop drinking the KoolAid.

That is precisely my point.

skeptic — Fri, 02 Sep 2011 04:00:00 +0000

That is precisely my point. Some companies pay a small group of bearded chaps to keep an eye on the future and what might be useful. Others leave it to their peers and competitors, and adopt what works.
The other 95%-100% of staff are not paid to innovate, they're paid to get a job done. I completely agree all this waffle about innovation is misleading bullshit.

PS. Cowboys aren't cowboys because they innovate. They are cowboys because they refuse to be managed or accountable.

Circumscribing IT

L. Morgan Stanislaw — Thu, 01 Sep 2011 17:01:54 +0000

You write, " Our primary job in IT is to keep the lights on and to do "normal" implementation and upgrade of services."

I believe this describes ITSM (information technology service management). I also believe that it short changes research and development and computer science to limit all of information technology to a service.

You seem to be arguing for the separation of IT, understood as ITSM, from research and development and computer science. If you are, then I agree with you. It behooves managers everywhere to get this straight and to inform their staff that they are not being paid to innovate.

But the synecdoche that IT is ITSM does a disservice to information technology--unless ITSM leaders, especially prominent and articulate spokesmen such as yourself--spread the word that IT and computer science and engineering must be sharply distinguished. That may be the problem with "tech cowboys": their managers write job descriptions that misleadingly suggest their staff will be working with exciting technologies, with the unexpressed implication that they will play a role in their development, when in fact they will be providing services. Period. Who hired those tech cowboys in the first place? How were they misled into believing their jobs involved something other than service? Did they uniformly mislead themselves? With all the focus of ITSM on behavior, surely the architects of ITSM have an answer.

If "IT is ITSM" not just a synechdoche, what would you make of the National Institute of Standards and Technology http:www.nist.gov, especially the NIST Technology Portal: http://www.nist.gov/information-technology-portal.cfm ?
Are they limiting their focus to providing services, or are they actively involved with the development of technologies and standards around therse? I don't see them insisting that NIST's job is to provide a service. I see them concerned with the development of new technologies and services. They even have an Information Technology Laboratory. If we limit IT to ITSM, NIST would have to jettison its laboratory. It would not have a division of applied and computational mathematics. They would not be investigating cloud computing.

Maybe you're right: IT should be understood as ITSM, and it should never be conflated with computer science and engineering. In that case, it is up to the ITSM industry to make the point that IT does not hire innovators. IT managers should make this point up front so that they avoid hiring people they later feel the need to denigrate as cowboys.

Whither ITSM?

Cornelius Fitzedward Pope II — Thu, 01 Sep 2011 14:17:15 +0000

" You can contract out the execution of risk mitigation (Cloud). You can't contract out of accountability for risk (governance). The more we outsource the more important risk management becomes, not less. I'm appalled anyone would suggest otherwise."

But that's the point: once computing becomes a utility, there is virtually nothing to distinguish IT services from facilities services or electrical services. There is very little IT in it. How much governance can you propose around wall sockets? At that point would it deserve volume upon volume of explication?

By the way, most people who contract out computing services want those cycles--they aren't paying for "execution of risk mitigation" per se. That sounds like paying for due diligence for its own sake--presumably they want to compute something for less than it would cost otherwise.

The IT Skeptic - Comments for "Cloud is a distraction to IT&#039;s day job"