I’d like to start a new, short series on IT staffing, looking at the issues from a slightly different angle.
We’ll start with the typical IT shop. It may be the kind that Nicholas Carr suggested will go away, but right now, it’s likely the most familiar to you and me.
Let’s look at the staffing needs of that IT shop over time. If it’s a healthy organization, the staffing needs look something like this:
Yes, I know, it looks all over the map, but that’s okay. The up-and-down motion you see above corresponds to a natural cycle of projects — starting off with a few key people making planning, then leading to a ramp-up in staff to do the work. As the go-live approaches, the technical staff begin to slowly trail off, until, eventually, we only have a few people left to keep the lights on. Then some executive gets a new idea, and the cycle begins anew.
To simplify just a bit, if we try to fit the curve to a line, we find something like this:
Of course, this assumes one project at a time. Most larger organizations have multiple projects, dozens of projects, hundreds of projects at a time, each with an ebb and flow. The company may have a portfolio management organization, or PMO, who’s only job is to keep straight the staffing and skills needs, and try to keep the company running at 100% capacity.
That said, no matter how hard they try, I find organizations have this kind of natural ebb and flow.
Until they understand the flow, in my experience, companies tend to think about hiring in one of two ways. They can either peg hiring to the minimal needs, or to the maximal needs.
Hiring to the minimum
Hiring to the min, or ‘below the line’, means drawing a line at the bottom of the demand curve. This guarantees you’ll never have excess capacity. It’s also cheap — at least, cheap in the short run. Companies that hire this way simply can not accomplish the goals they set, thus the products are late and buggy, the customers unhappy, the sales goals unmet … so next year, there won’t be money for additional staff.
We can all guess how this turns out.
The obvious alternative to hiring below the line is to hire above it. Believe it or not, some companies actually do this.
Hiring to maximum demand
The blue in the picture above is waste — or at least, undirected team capacity. While some companies like Google embrace ideas like 20% time, the fact is that much blue will make many a CEO wince.
There are some rare companies at a place in the growth cycle where they are constrained by people, but by money; where the company can throw a hundred thousand dollars at people and get two hundred thousand back from the marketplace. So this strategy might just work for Google in 2008, Groupon in 2009, or AirBnB in 2010.
For the rest of us, though, it seems unlikely.
The Third Way
The “classic” HR solution to this problem is staff permanent employees to the bottom line, but fill in the red with contractors, temps, staffing agencies, and ‘partner’ organizations. Now we could talk about the true cost of ramp-up for contractors, but, for now, let’s assume that strategy works.
Do you want to be a red person or a blue person?
It may sound like a silly question, but there’s a method here.
Think on it: The blue people (for lack of a better term), are the people above the sliced line. They will be creating new systems, setting up servers, creating policies, adding new capacity, teaching to fish. These people are, to borrow a phrase, the pioneers.
To blue people, projects are “new every morning”, and, to be clear, risk and change are just a part of life.
The red people — the ones below the minimal staffing line — are operational people. They come in, know what they have to do, do it well, and expect a paycheck and some permanence. The red people are farmers, creating accounts, resetting up passwords, troubleshooting, doing predictable, well-defined work.
Note that I’m not talking about personal politics, or the details of your organization. Yes, it is possible that your boss likes you because you are willing to dive into new technologies, and that gives you job security.
Instead, I’m talking about the personality types that will tend to fit into different roles if companies take this approach.
And mind you, they are taking this approach.
If you know which type you’d rather been, you can steer your career in that direction.
If you don’t steer, you’ll likely end up wherever someone else, some levels of the chain above, decides you ought to be.
As Socrates said “The unexamined life is not worth living.”
Take the wheel.
More to come.
Note: This is an interlude. I want to talk more about the future of the IT profession, but I just checked my account summary from Amazon.com, and I feel sort of like Adam Savage from Mythbusters, when he accidentally carried some razor blades on a plane and no one noticed.
You see, I thought I was on a new tier, called the Free Usage Tier, that gets you 750 hours of CPU time a month along with 30 GB of data transfer per month, all for the first year. My back-of-the-envelope math says there are 24*31, or, at most, 744 hours in a month. In other words, unless you have the demand to spool up multiple machines, there is really no possible way to get dinged. So, while they want your credit card, there really is no financial risk.
But, like I said … then I got the bill.
I mean, yes, my editor told me that he done his own exploration, and forgot to turn something off, and got a small ding on his credit card, but that just a good warning for me. I would be extra careful to turn everything off, and warned everyone else to do the same.
And I was.
I ended up taking a small hit anyway, $8.41 for the month of June. It seemed odd, but that’s no big deal. I went back in, turned off an inactive server that I could have sworn I killed off in the past, and let Amazon have a couple of discount combo meals, on me.
Just to be sure, I checked again today. Guess what?
Another $1.82 of charges so far for the month of July. $1.81 is labelled “Electric Compute Cloud”, and one cent is for bandwidth. What’s that about?
Taking a closer look, I see two things:
(A) It’s 61 hours of fees on a WINDOWS machine — capital W Windows.
(B) The one penny is a ‘regional data fee.’
The windows machine fee I can sort of understand; it turns out the personal AWS license only covers Linux Machines. This makes sense to me, as Microsoft likely back-bills Amazon for the operating system, whereas Linux is free like water.
Also notice the sixty-one hours of charges.
After I got the previous bill, I immediately turned off my single EC2 instance … but that immediately was some time after I got the email, which, likely, was some time after the time cutoff for the fee. If that total was around two and a half days, well, that’s sixty-one hours.
I have no idea what the one cent is for. I have no visibility into it; I can’t explain it, don’t know how I could have predicted it. More than that, I can’t even talk to a human and ask — at least not without upgrading to a premium plan. For now, I paid the penny, sent a cancellation notice, and intend to check vigorously and often for new charges!
Now imagine that the bill is not for a proof-of-concept demonstration of the cloud, but instead an actual enterprise service.
How do you know how much it will cost? How do you budget? How you do you prevent hidden fees?
Suddenly the pain point of heavy load has shifted.
In the old days
We had a different risk. The classic example of the old days was the IBM commercial, a team launches a website with Champagne and Caviar. The team howls with glee as the ticker shows more hits — and keeps howling as the ticker goes crazy. Slowly, eventually, the howls die off as the team realizes the site is too popular; it will quickly become overloaded and crash.
With tools like EC2, the crash won’t come to your site.
Instead, it will be to your checkbook.
Yes, there are tools that are coming to address this, even services like the one discussed on this Amazon EC2 Forum post.
But doesn’t it seem strange to have to set up your own scripts to monitor momentary charges, and warn on the event of a spike, or to have to pay yet another party to monitor cloud usage? I mean, if your utility bills suddenly spike, they should call you, right?
The cloud is young. We’ve got new risks, and plenty of work to do.
Speaking of work to do …
Next time: More on the future of the IT profession, and how we can thrive.
In May of 2003, then the editor-at-large for the Harvard Business Review, published an important paper in the Harvard Business review titled IT Doesn’t Matter.
Notice I said important — the paper is all of eleven pages long, so it won’t take too long to read, and it costs of of six dollars and fifty cents to download as a PDF from Amazon.com for a digital download. The Amazon PDF also includes seventeen pages of commentary.
I’m serious. It’s all of six bucks. I can wait.
… time passes …
The basic premise of Carr’s article was that IT services were turning into commodities; that it would be harder and harder to wrangle competitive advantage by throwing money at technology. In fact, if you follow Carr’s logic, it might even make sense to find the work that can be done the same by anyone, and outsource that work to a strategic partner who could work for many customers and offer economies of scale. (That’s fancy talk for “cheap ‘cuz he has a lot of customers.”)
I dare say I’m a little more familiar with this than most folks, because when I was finishing up my master’s program at good ol’ Grand Valley State University, our advisor decide to make that very article the theme of capstone for our entire cohort. In other words, about fifteen of us, group in twos and threes, all had to write papers to respond to Carr’s article.
Some folks chose to write about technologies they believed could still offer advantage — there was a paper on six sigma, one on Enterprise Application Integration, and one on Mobile IT that I could actually find, mostly because the name “Mobile IT Matters” is a play on words.
In our paper, we took the opposite position to many people in our class; that in some cases, IT is not a strategic asset and should be outsourced. Our paper provided a value chain, from simple repeatable work (basic IT helpdesk) to moderately complex work like systems maintenance, to high-value work like developing the software your company will sell directly.
We argued to outsource what you can, but keep the functions that give you competitive advantage. Then our paper provided advice on how to figure out where to draw the line.
Back to Nicholas Carr.
His article was important, but I must say, it didn’t drive much change. Or, at least, the change wasn’t super-visible. People grumbled and disagreed, but the article came out in May of 2003, and we were just starting to pick up the economic cycle. Yes, outsourcing was picking up, but every practical conversation I had about outsourcing was driven by promised or expected savings in cost, usually by a difference in the hourly cost of labor.
The big thing I noticed, at the time, was that even if you could outsource some things, you’d still need a datacenter, still need air conditioning and cables, boxes and power. On this, Carr’s electrical analogy falls down; there was no grid.
Thing again … maybe he was just early.
Consider the typical small IT shop, for a decent-sized manufacturing company today. Sure, they need a website, but they probably rent one from GoDaddy. They might need accounting software, but Intuit offers quickbooks for what, twenty-five bucks a month?
No server, no license, no data center, just buy a cable modem and pay-per-month.
They need project management software, and there’s BaseCamp. Want to stich together an e-commerce site? There’s Amazon and PayPal, or E-bay, or … take your pick.
Suddenly, eight years later, you can stitch together a bunch of services. Oh, you might have to manage a dozen logins at a time and have problems when people are hired or quit, but they are surmountable problems.
Software As A Service can step in to provide the power grid for IT.
At the same time, there are those millennials. Those kids are tech savvy. They’ll go ahead and sign up forthe freemium version for the product, get it working, then ask for budget thirty days later.
So you’ve got the services to work remotely, and the employees with the tech skills to set things up without IT.
What’s the poor IT manager to do?
More to come.
Last time I introduced Andy Lester and his book Land The Tech Job You Love. Today we return to ask about the specifics of the book; what Andy recommends to job seekers, and where can go to learn more about it.
Matt: Tell me about the book; how is it structured?
Andy: It’s in two halves: Finding the job and then applying and interviewing.
The first half is about the part of the process that’s entirely about you, that you do by yourself. The second is the parts where you are actually interviewing with the company.
I made a point of splitting the chapter on resumes into two chapters. The first discusses the words that you’re going to put on your resume, and the second talks about presentation and format. One of the things that I’ve seen from years of reading Slashdot and Reddit is that people think primarily about formatting on the resume, and pay very little attention to what they’re actually saying. I hope to help people get past that.
I’m also emphatic that you don’t have a resume, just one resume you send out for every job. You have a base resume that you then modify for every job for which you apply. No two jobs should get the same resume, because no two companies and positions are the same. For one company, you may want to emphasize your database skills, and for another, your educational background is the most interesting. Yes, it takes time to tailor every resume you send out, but hey, you want the job or not? Besides, if you don’t have a job, what else can you be doing that’s more important than everything you can to get a job?
Matt: How do you find the company you’d like to work for? It sounds like you are not suggesting the “numbers game” resume approach …
Andy: There aren’t 200 jobs out there that will make you happy, so why are you sending out 200 resumes?
Instead of going scattershot looking for any position possible, start looking for the types of companies that you’d like to work for, or doing the kind of work you’d want to be doing as well. Talk to whoever you can. Ask for pointers on what kinds of companies might be a good fit. For instance, if I was looking for a job, I might drop you an email saying “Hey, Matt, you know I’m big into automated testing like you are. Can you point me at any companies that are strong in that area, or could use help getting ramped up with testing?” Note that I’m not asking for a job, but just help along the way. When the requests you make of your contacts are small and non-imposing, it’s much easier to ask for help.
Matt: You mentioned the second half was about interview tips. I expect that all of our readers know to show up ten minutes early, to get a good nights sleep, and to dress a level higher than the job would generally require. Could you share a few tips that have a bit more, well … depth?
Andy: Actually, you might be surprised by how many people don’t know those interview tips. I”m finding more and more that the people raised on the Internet have apparently never picked up a book on job hunting of any kind. I often tell job hunters who are completely new to the job hunt to go to their local public library and start there. You’ll find dozens of books that will have a solid overview of the process.
My #1 tip for interviews is to have stories to tell. The interviewer is going to be asking about your skills, and a story is the best way to do it. Don’t just say “Yes, I know Oracle’s PL/SQL” when you can say “I’ve been using PL/SQL for three years, and I had to implement a Foo system in it, and convert a Frobnitz application from Postgresql to PL/SQL.”
The first answer says “yes”, the second answer says “Yes, and here are details to support it.”
The #2 tip is to put yourself in the shoes of the hiring manager. What is it that she wants to know about you? What problems does she have to solve? The hiring manager wants to hire you. She wants you to be the ideal candidate, so she can hire you and then get back to the rest of her day-to-day job. She is on your side. What you have to do is tell her the things she wants to know so it’s a slam-dunk decision.
Matt: Let’s say someone is living in a medium-sized area, and there are tech jobs, but he lacks some specific buzzwords and doesn’t want to move. How can a person in that situation land a great job? Do you have any advice?
Andy: If they’re buzzwords that he wants to learn, then start by learning them. Spend an hour less a night watching TV, and read a book on the topic, and create a homemade project that uses that technology.
Want to learn Ruby? Or a new variant of SQL? Or HTML5? The technical knowledge is out there, and you can spent the time to learn it. You’ll just have to do it on your own.
Matt: I can see that working for open-source tools (I just did a tutorial post on how to get started with EC2), but can that work for large, expensive databases, or, say, administering MS Exchange? For that matter, have you seen a lot of people have genuine success with that approach?
Andy: A fantastic solution, if you can find it, is to join an open source project focused on the object of your learning. There’s a huge difference between putting on your resume that you’re teaching yourself Ruby, and that you’ve been contributing to the RubyWhatever project.
As you point out, this isn’t always possible. An alternative might be to take a class at your local community college that is at least in the same general area as the topic. You could also find a user group, say, the Des Moines Exchange Admin User Group, and attend meetings. Mailing lists are fantastic for this, too. Just join a mailing list and read the archives and learn from the problems and experiences of others. It’s not as good a learning experience as having your own Exchange server to play with, but it’s far better than nothing.
Matt: thank you for you time today Andy; where can our readers go for more?
Andy: You’re very welcome, Matt. If your readers want more, they can visit my blog about jobs and programming at petdance.com. I’m glad to answer questions from readers when possible, too.
It’s a tough world out there. Unemployment runs at 9%, but if you count the under-employed, part-time, or those out of work more than two years, the percentage could be twice that.
Then you have employers, a fickle lot, that like to require a very specific skill set, down to the level of sifting out people who have experience administering the wrong point-release of specific operating systems.
Let’s be frank: The first part, “land the tech job” is hard enough, and here Andy comes promising the second.
I thought it was time to talk to the gentleman, man-to-man. (Plus I’d let you watch, because I’m that kind of guy.)
More seriously, Andy wrote a book about developing habits to get, and keep, a job suited to your skills and temperament — and offered to talk to us about it.
In Part I of this interview, we’ll talk about the experiences and motivations that Andy drew on to write the book.
Matt: You’ve been a programmer, manager, and technology evangelist. What inspired you to write a book such a human-resources-y topic?
Andy: Years of hiring programmers. I’ve had so many people interview for programmer positions with two big failures. First, tech people tend to not like to talk about themselves, and you have to sell yourself to get a job, because if you don’t, someone else is going to beat you to it. That’s not the entire problem, but it’s the tip of the iceberg. Second, I talked to many people who didn’t seem to especially care what job they got. They just wanted to come in and write some code and go home. This seemed like such a shame, because I figure that life is too short to spend working in a job that you don’t love. You spend as much time at the office as you spend waking hours with your spouse, so why not love what you’re doing?
Matt: You’ve been a hiring manager since about the time we first met, in 2003. Of all the candidates you’ve seen, what would you say is the #1 mistake you’ve seen?
Andy: I always ask for printed code samples before an interview. I want them printed so that the candidate and I can look at them in the interview together, and I can get a feel for the candidate’s design and coding decisions.
So this guy comes in at 9:10 for a 9:00 interview, which is Strikes #1 and 2 against him right there.
He doesn’t apologize for being late, and hands me an orange 3.5″ floppy disk and says “Here’s my code samples, my printer ran out of ink this morning.”
Never mind that I didn’t have a drive capable of reading a floppy, even years back when this happened, but he told me quite a lot about himself.
First, he was unable to complete his first assignment as directed. I said to do X, and he didn’t.
Matt: Let me guess — second — it told you that he was comfortable transferring his problems to you?
Andy: Exactly. Third, he waited until the morning of this important meeting to do the assignment. Fourth, he didn’t have the presence of mind to go to a Kinko’s and print off copies.
Matt: Can I ask, what were the top two or three things you’ve seen as a hiring manager that impressed you? What were the good things?
Andy: I’m always impressed when a candidate has clearly done his or her homework and researched the company or me. I always give my name when I’m going to interview someone, giving them ample opportunity to find out about me on the web. If you can find blog posts or mailing list messages from your interviewer, it can give you insight into what he and the company need. This isn’t creepy. I’ve already Googled the candidate before calling them in for an interview, and they should have the foresight to do the same in return.
At the very least, everyone should find out as much about the company with which they’re interviewing before going in for the meeting. I wish it weren’t so uncommon that it impresses me when people do it.
Candidates who are well-prepared for the interview and work to tell about their value to their companies in past positions always make a solid impression. It shows that they know I’m hiring them for a job, not just for the heck of it.
In Part II, we’ll dig into the specifics of Andy’s advice for Job seekers, and where to go for more.
So far, we’ve signed up for a personal Amazon Web Services Account, learned a little bit about the Amazon Management Console, and, yes, even created a server in the cloud. Now if only we could actually do something with it …
Suddenly I have an idea for a follow-up post. 🙂
Today I’ll show you how to connect to that server in the cloud, accessing it through Remote Desktop, run software on it, and finally, so your credit card does not get dinged, how to shut the server down.
First, you need to follow the instructions in the previous tutorial; you should end up looking at the Amazon Web Services Console, something like this:
Now things get interesting.
The green light there indicates that the server is booted, but it may not yet have all services running … especially the services we need to connect. The easiest way to get to our server is to wait, about a half-hour, for Amazon to make sure the server is ‘clean.’
In the mean time, we need something: Remote Desktop software to connect to our server. Remote desktop comes standard on Windows Vista and newer machines, but is you have XP or a Mac, you’ll need to download it. You can get that software for free online; both the WindowsXP Version and the Macintosh Version have a free download.
Once we have Remote Desktop, you’ll have to wait; my recommendation is a half-hour, for all the services to be up.
Now Get The Windows Password
Once the services are up, we’ll need to retrieve the the administrative password for the machine. To do this, check the checkbox to the left of the instance to indicate it, then click on instance actions and “Get Windows Password”. (See example below)
Once you click retrieve, you’ll be asked for a private key, in order to decrypt the password from the server:
Do this this you will need that .pem key file you created earlier. Once you upload the file you will get a windows password. Save that to a file, or at least copy it to your clipboard with control-V.
Whew. Now we can actually connect to the machine.
It’s time to Log in to our cloud-based server. Yay!
One more time — use instance management again and click connect. This should bring up another dialog box, and you’ll have the opportunity to download a shortcut file , with the extension .rdp. If remote desktop is configured correctly, you can open the file with remote desktop. (Otherwise, save the file to your hard drive, open remote desktop, and tell it to open the file.)
Once remote desktop has the file loaded, Click Connect on remote desktop and you’ll come to a login screen:
Paste the password, leave domain blank, and click ok; ignore any certificate warnings.
Congratulations — you are in your server!
But … what can we do with it?
Of course, the value of any server is limited to the application we had in mind. Our goal today was to have a server, which isn’t saying much.
Three things we could do with this server are to test in internet explorer 8, to test installing applications on Windows Server 2008 (if we didn’t have a box handy), or to use the server as a storage place for files.
And that;s the real rub of cloud computing. Without an application, ‘give us some of the cloud stuffs’ doesn’t really mean anything.
More on cloud-based apps to come, but today promised to keep things under an hour. Today we wanted to get a real, live server up and running in the cloud, and I do believe we’ve done that.
With this foundation in place, we can add more in the future. For now, though …
Off — Off — Turn it Off!!!
In control panel, select Instance Management->Terminate, then Yes, Terminate. Please do, this, you must do this. If you do not do this, expect a ding from your credit card in a year.
Closing the loop – what we’ve learned
If you followed the instructions in this tutorial, you create an AWS personal account, created a server, and got into it with remote desktop.
Congratulations; suddenly the “cloud” is a less mystical and magical place, and more a think you can touch and feel, or at least a little bit more of a thing.
You’ve also probably recognized that feeling of “my goodness, this doesn’t actually do anything”, and you’re right. That’s what those cloud application vendors I introduced you to earlier have been saying for years: Building applications on top of the cloud is expensive and time consuming, why build when you can rent?
Why build indeed?
More to come.
In the first blog entry I wrote about how to dip your feet into the cloud, mostly by using someone else’s cloud-based application. In the second I talked about how to move the cloud discussion from one of emotion to something a little more nuanced, just a little bit more based on reason.
One thing those techniques can buy you is time; time to go figure out how we are going to do this thing called the cloud, or CRM, or whatever else is the buzzword of the moment.
Let’s say it’s the cloud — what next?
In this article, I’ll walk you through creating a free server in the cloud in about an hour.
No really, we’re going stop talking about Amazon Web Services and start using them. To do this, we’ll create an Amazon Web Services (AWS) account, create a server in the cloud, then connect to it.
Whew. Here Goes.
What You Will Need (And A Warning)
All you need to get started with Amazon Web Services (AWS) is an Amazon.com classic account. That’s right; we’ll be super-charging our Amazon Account to become an Amazon Web Service personal account.
Notice that word personal. In order to encourage adoption, AWS gives away 750 CPU hours per month free for twelve months. That means you as long as Amazon doesn’t need to spool up additional servers, and as long as you turn off your instances when you are done testing, the service will be free.
Note: That’s a really, really important if. In the event that you follow this tutorial and forget to turn your instances off, you will see a bill in the mail, likely in the area of 8-10 cents per CPU hour, for as much as a month.
Don’t forget to turn off your machines. If you do forget, IT Knowledge Exchange nor Matthew Heusser are responsible for blah blah blah legal stuff here.
Step One: 90% of everything is Signing Up
First log into Amazon with your regular old account, then point your web browser to this URL:
1. Click sign up now then follow the instructions to create an Amazon Web Services Account.
2. Amazon will need to verify your identity by phone. To do this, Amazon will give you a special code and the call the phone number on your account. You’ll need to enter that code, then press continue.
3. Next AWS will email you a confirmation; check your email.
Once you have that email, we can move on to actually creating your first server.
Step Two: Create Your First EC2 Server
EC2 is the “Elastic Compute Cloud” (One ‘E’ and two ‘C’s)
The word elastic is important; the number of servers we are using will spool up and down with demand, kind of like your strechy pants that get wider around thanksgiving time if need be. (Okay, my strechy pants. Sheesh.)
For the most part, signing up is easy, it is in creating the servers that people get stuck.
It’s not just the command-line tools. It’s also the orchestration of the servers, the connecting them to a web-page, and, yes, the security issues involved in setting up key-value pairs.
For this time, let’s skip all that, and use remote server administration through a control panel.
To do this, go to this URL:
Select EC2 in the drop down and check the box — like in the example above — then sign if. (If you;d like, you could explore S3, Amazon’s file storage in the cloud option; more about that some other time.)
Once you log in to the console, you should see something like this:
This is the basic management console; the list of Amazon Cloud Services as tabs at the top.
Click launch instance.
You will see a large number of choices; select “Microsoft Windows Server 2008 Base.”
At this point you will work through a five step wizard. You can get by with the defaults for the first and second step (‘Instance Details’); we don’t need to worry about getting a large server or deal with integrated security issues.
When you get to step three ‘Create Key Pair’, you will need to create a key and save it to your computer’s hard drive. I will call this file a .PEM file — This is important. We will need our end of that key (the ‘private key’) to log into our server in the cloud. Note: Matt had problems doing this in Chrome; best browser is probably FireFox.
For firewall you can accept the defaults, then click ‘Launch.’
Ta-Da. Your instance is launching. Wait five minutes and click “close.”
You’ll come back to the Command Console page, but what’s that at right … it says one running instance! Click that.
You’ll come back to the EC2 Management Console Page, for your running instances.
Congratulations! You’ve got a windows-based server up in the cloud.
Oh course, we don’t know how to do anything with it yet, or even shut it down.
I’ll cover that in the next blog post.
Last time I talked about how to respond when the big boss walks into your office and says something like “What are we doing about the cloud? We need some of that cloud stuff.”
I tried to make that advice hold true for most teams — but if your organization has data privacy and security concerns, the question becomes a lot more complex.
Or does it?
Think about both of those statements:
“We need some of that cloud stuffs”
“We can’t possibly go to the cloud, because of regulations and data security issues”
In neither case do we have any data; we don’t what kind of uptime or service level agreements we could get. We don’t know what the applicable regulations are, we don’t know the cost of the conversion or ongoing operations.
In both of these cases, we’ve jumped to conclusions based on some sort of faith.
In other words, what looks like a conclusion is really more of an emotional response.
It turns out that is kind of a big deal.
In “Switch: How to Change Things When Change is Hard“, authors Chip and Dan Heath argue that the brain is constantly fighting between the emotional side and reason — and emotions frequently win. (Those of us who have vowed to get up in the morning and exercise, or give up fatty foods, and failed, likely know what they mean.)
Likewise, if you’ve ever responded to an challenge like “prove it” by brining all your data to the next meeting — all your pie charts, graphs, and powerpoints, only to be faced with complete apathy and unresponsiveness, well, you’ve seen the power of emotion in the boardroom too. Again, Chip and Dan Heath suggest that reason might win the meeting, but without an emotional response, the actual action items to make the change will keep being rescheduled, over-looked, and ignored, until they eventually go away.
Another way to put it: You might win intellectual assent for your idea, but without hitting someone’s emotions, it’s unlikely that the project will get to be your priority, or get funding, or get on the corporate projects list. It’s kind of hard to move to the cloud at night, for free, in your spare time. If you somehow pulled it off, though, I expect you might get brought into a meeting to talk about “Governance”, don’t you think?
Defeating the Lizard Brain
Seth Godin calls this emotive side the “Lizard Brain“, because it is the kind of brain that chickens and reptiles have — a brain driven by fear, greed, and the desire to continue the species. Yet we can trick our lizard brain. Chip and Dan Heath use the example of an alarm clock with wheels, that forces you to get up and chase it in order to press the snooze button; once you’ve pressed snooze, you’re up anyway.
We can do this in the IT Department.
Matt’s Hasty, Generally, Possibly Incorrect Guess
I’m going to take a guess here, based entirely on intuition.
If your organization feels some compelling need to go to the cloud right now, then the corporate culture is likely one of innovation, or at least early adoption.
As the saying goes, you can tell the early adopters, because they’ll stand in line four twelve hours to get a new iPad, just to be the first people to have it. Of course, in a week, everyone else will have one too, but for that week … wow. They’re ahead of the curve.
Likewise, if the company is fighting tooth and nail to find reasons not to change, you’re likely in the early majority, if not the late majority, on the technology adoption lifecycle.
As my friend Eugene Lee recently said about these two groups: “If you come to early adopters with an 80% solution, they’ll work with you to figure it out. If you come to the late majority with that 80% solution, they’ll response ‘call me back when you’ve got it all figured out.’
Right now, today, cloud technologies are in the early adopter phase.
Now if you agree with the big boss — no problem. If he’s worried about security and so are you, hey, great, you’ve got some time to figure it out. Likewise, if the company wants to throw time and money at the issue and you’d like to get experience with the news tools — hey, cool. You might need to put some effort into setting expectations, but for the most part, you’re good.
It’s when things are different that you’ve got a problem.
Encouraging Late Adopters
The lizard brain is motivated by fear, but fear can cut both ways; you can implement buggy systems or be left behind, trying to sell an MS-DOS based application to Windows Users.
Most late adopters do one thing: Follow the Herd. Or, as I’m sure you’ve heard “No one ever got fired for buying Microsoft.”
The Early Majority needs to know the problem has been solved before, and solved well, by other companies. You can do this through Lunches, Case Studies, References in Magazines, Interviews, or Articles. Once someone else has done the work, there is precedence – and that precedence can overcome a host of objections about regulations, audits, and standards.
The Late Majority, on other hand, adopts technologies when it looks like they are about to be left behind. You might not be able to drag a Late Majority-Culture to the cloud today, but the time is coming. When cloud adoption approaches that of Social Media, which has an 86% adoption rate in US Global 100 companies, your company will want to have an answer. Likewise, Late Majority Companies tend to be risk averse, so the time to start the experiment that might be fully implemented later … that time is now, isn’t it?
If your company is an early adopter, you might get pressure from the other direction — no, it might not be a great idea to put exchange “in the cloud” next week (whatever that means.)
When you try to deal with unrealistic expectations, yes, you can use reason, but try to do it in a way that can create an emotive response. For example “Is it okay if our services go down for five business days? Because that just happened to Amazon’s Cloud in April.” You might also want to mention the risk of a customer-data breach, yes, but also point out that it happened to Sony’s Datacenter in April, entirely because Sony’s model required it’s systems to be available to general public outside the firewall … just like most public clouds.
By moving from a potential threat to a systems failure, one that happened to a real company, with real security, who’s name we recognize, we transform the problem from the realm of theory to one of practice.
A Final Thought
Now I’m not saying that IT should drive every business decision, nor am suggesting you manipulate your boss to get your way. Instead I tried to provide a few techniques to align emotions with the intellect, to help people come to the best possible decision, instead of allowing themselves to be driven entirely by fear and greed.
But what do you think? I look forward to your comments.
Welcome to “Unchartered Waters”, my blog exploring new ideas and concepts in information technology.
Of course, if you have more than a few grey hairs in this game, you’ve likely seen “new ideas” before. Two years ago, Web Services were going to re-define the way we delivered services. Two years before that, it was Customer Relationship Management (CRM).
Before that, it was the Enterprise Service Bus (ESB), and, before that, Enterprise Resource Planning (ERP). Some readers might even have had the familiar experience of a manager or executive walking into the room, saying something like “We need XML. Can we get some XML? How can we use XML?”
Today, it’s Cloud Computing, “Governance”, “Portfolio Management”, Server Virtualization, or integrating Mobile Devices into the organization.
It’s easy for us to complain about these things. “Oh, yes”, we say “We’ve seen this before. Everything old is new again. New paradigms and all that.”
And yet, every now and again, something does happen. Personal Computers did enter into the IT shop, and things did shift, and companies that took advantage of these new technologies gained advantage in the marketplace. Also note: The IT Departments that tried to block these innovations didn’t just slow the company down and eventually fail in that blockage — no, in many cases, those department went away.
Further Note: If your organization is more than a few hundred people, it’s very likely that somewhere, down the hall, someone is checking email using an iPad he bought out of pocket because “those darn IT guys” wouldn’t supply him one.
If we are to be successful in technology long-term, we’re going to have to separate the true opportunities from the fads — and know how to respond with grace and skill.
That’s what this blog is about.
Say, for example, the big boss walks in your office in 2011, trade magazine in-hand, saying something like “Why aren’t we using Cloud Technologies? What’s our plan for adoption.”
We need an answer, and it’d better be good.
Dipping our Feet In The Cloud Waters
To get started, let me suggest that you consider using some cloud services (“renting” cpus), instead of creating cloud servers. Here are some ideas:
* Cloud Backup. Several companies offer to backup data offsite, in the cloud, automatically, for a modest fee. You can generally find a nice “wrapper” product, like Zmanda, or, for the ambitious, do it yourself with something like Amazon’s Simple Story Service (S3). (You custom S3 tool might never see production, but that’s kind of the point: To experiment in a cheap way that doesn’t blow anyone’s budget.)
* File Synchronization. Between laptop, phone, home computer, and iPad, today’s power user is going to have a lot of places to store files … and emailing them to himself will get old fast. Apple’s iCloud Service may have the most buzz, but it’s certainly not the first in that space. There are a half-dozen iCloud competitors, most of whom work with windows natively. Running under native windows can be as simply as saving files to a specific location — and yes, DropBox has a free version.
* Cloud Performance Test. Vendors like SOASTA, LoadStorm, and BrowserMob all offer cloud-based performance test tools. Give these tools some URLs and instructions and they can send a hundred, a thousand, or ten thousand simultaneous requests to a website and return with the pretty performance metrics management likes to see.
Beyond “pure” cloud, there are Software As a Service Alternatives as well:
* Collaboration. Does your company have anything to improve within the business in the same way that twitter and facebook has done outside of it? Jive, Socialtext, and Confluence all offer web-based collaboration software, for a fraction of the cost (and none of the admin hassle!) of Microsoft Sharepoint.
* Project Management. Both BaseCamp and Gnatter are two web-based tools for project management. With these type of tools there is nothing to install, nothing to synchronize, no emailing of word documents back and forth or re-typing of status into ten or fifteen systems. Best of all, you can run a project or two, and, if you don’t like it, drop the tool, without having to worry about “porting” anything back or forth.
The Bottom Line
It’s hard to respond to a vague mandate like “move to the cloud”; yet such an idea does represent real opportunity. Yes, I’ll have more to say about setting up an adiministering cloud-based systems yourself, and plenty to say about security, privacy, and other issues of corporate risk. For now, if you have projects that are not classified, consider getting your feet wet by using someone else’e cloud-based service. Most of these services are free for thirty days, or have one-to-five user “freemium” models. Even the pay plans tend to start at reasonable prices, in the $50/month range.
So check out a product with a freemium model; find your most early-adopting project team and offer them a pilot project. Write up the results, and ask for some funding to do a real test. If you get the funding, great; rinse, lather and repeat.
If not, well, you’ve got an answer to the question. The reason we aren’t doing “this cloud thing” is because corporate chose not to fund the project.
Question asked and answered.