More on this topic:
Things are changing in the Microsoft IT world. It's happening slowly, but it's happening. We've reached an inflection point, or are reaching it soon – and whether or not today's IT administrators continue to have a job (or at least, the same job) is very much in question.
Why Microsoft IT Admins Are Losing Their Jobs
How happy would you be if, every time you needed a light turned on in your house, you had to call the power company and have them send a tech out to rig up the wiring? Not happy. But you don't do that, because that isn't how utilities work. They're largely automated.
And IT needs to become that kind of utility. Not because we should (although of course we should), but because the business is going to demand it. Large competitive companies are already doing it, and they're loving it. IT is a utility for them. When they want to roll out some new business service -- a Web site, a VM, whatever -- they no longer have to account for the IT overhead needed to implement the service. They've already invested the overhead in automating it all. They know that, once they decide to go ahead, they'll just flip a switch, a miracle will occur, and the new service will be online. It'll be backed up, monitored, managed, patched, and everything -- automatically.
You see, the tools all exist. A lot of Microsoft IT admins just haven't been paying attention. PowerShell's here. System Center is doing this stuff already. OS-level features are supporting this kind of automation. The VMware folks have got a lot of the same automation in place. This is all possible, not some vision of the future.
And what the big companies do successfully, the smaller companies will eventually see and want. So if you're an IT pro who's used to Remote Desktop, wizards, and doing stuff manually each time it needs to be done, you're going to be out of a job. The good news is that you can have another, better-paying job -- the job of creating the automated processes your organization needs.
The trick here is that a given organization needs markedly fewer Automators and Toolmakers than it needs button-clickers. So not everyone in your IT team is going to be needed. We're already seeing a significant falloff in mid-tier IT jobs, and a slight falloff in entry-level jobs. Just like every other part of the IT world, ever, Microsoft IT is consolidating into fewer, higher-end, higher-paying jobs.
So if you think PowerShell, System Center, and related tools and technologies "aren't my job" as a Microsoft IT admin... well, I'd like fries with that, please.
How You Become the New Microsoft IT Admin
Even Microsoft's certifications reflect the fact that Microsoft is marching toward this new inflection point. The new Server 2012 MCSE requires basic System Center knowledge, and the new "MCSE Private Cloud" certification incorporates nearly the whole darn System Center family.
Could you bet against Microsoft being successful in this push of theirs? Sure. Heck, I live in Las Vegas, we'll bet on anything. But you're on the losing side of this one if you think your IT job will always be the same. The economic pressures for Microsoft's direction are too high. This isn't a direction Microsoft chose, it's a direction forced upon them by today's business realities. We need to do more and more and more, with less and less and less, and automation is the way to do it. Companies are realizing they'd rather pay a few people a lot of money to make everything automated, than pay a lot of people less money to do it all manually. Is that fair to all the Microsoft IT folks who joined up thinking they wouldn't have to be programmers and toolmakers? Nope. But life's not fair.
Rather than betting against Microsoft on this, and getting crushed under the coming wave, get in front of it. Actually, you're too late to get in front -- but you can at least pull ahead a bit. Start looking at every process that your IT team does more than once, and figure out how you'd automate it. You're going to need to know all about System Center's capabilities -- all of System Center. You'll need to learn PowerShell, and it's going to take a serious effort, not just reading people's blogs and piecing together commands. You're going to have to learn to research, to find automation tools and technologies that fill whatever gaps you find.
And your employer may not pay for all of the training you'll need -- but it's an investment in you. Get your employer to at least put automation on your annual goals -- "automate 10 person-hours worth of manual labor each quarter" or something. Something you can measure, something that forces them to invest, since they're getting the lion's share of the eventual return on that investment. Commit to doing those things, so that you're the toolmaker in your organization. The one the company can't live without.
Because the alternative is not good. Remember, the square ones are the fish, and the round ones are the burgers.
Good luck.
Posted by Don Jones on 03/27/2013 at 11:45 AM0 comments
More on this topic:
Things are changing in the Microsoft IT world. It's happening slowly, but it's happening. We've reached an inflection point, or are reaching it soon – and whether or not today's IT administrators continue to have a job (or at least, the same job) is very much in question.
Now Hiring Smarter IT Pros
Microsoft has moved firmly into the platform world, with many of the native product administration tools being almost afterthoughts. Use Active Directory Users & Computers to manage a large directory? I don't think so.
Microsoft has realized that it can never build tools that will meet everyone's needs, and so the native tools are just the bare-bones basics that a small organization might be able to get by on. Instead, Microsoft is focusing more and more on building platforms -- great functionality. But how do you administer those platforms?
This is the new inflection point in the Microsoft IT world. Increasingly, Microsoft is giving us the building blocks for tools. Application Programming Interfaces (APIs) that let us touch product functionality directly and build our own tools. Microsoft even has a word for the new IT discipline: DevOps. In part, it means operations folks (admins) taking more responsibility for programming their own tools, so that they can implement their organization's specific processes.
Yes, programming. In many cases, the new operations API will be Windows PowerShell -- but not in all cases. You'll also be using tools like System Center Orchestrator, and may use ISV tools that let you build out your business processes.
In a way, this is completely unfair to the loyal Microsoft server fan. They got on board by clicking Next, Next, Finish, when the rest of the world was off running command-line tools and writing Perl scripts. Now, Microsoft is yanking the rug out from under them. "Psych! Turns out you have to be a programmer after all!"
But there's a reason for it -- and you can either embrace that reasoning, or close your eyes and wait for it to run you over.
Forget Private Cloud. Call it Util-IT-y.
So why is Microsoft so focused on making its loyal IT professionals become scripters and programmers? Funnily enough, it's the private cloud.
Go over to GoDaddy and buy a Web site for yourself. Or, go to Amazon and buy some AWS time. In both cases, you will not find some human being Remote Desktop-ing into a server to spin up a new VM, provision your service, and send you a confirmation e-mail. It's all done automatically when an authorized user (you, a paying customer) requests it. Hosting organizations like GoDaddy and AWS don't treat IT as overhead, they treat it as enablers. Their IT folks focus mainly on building tools that automate the entire business process. Someone buys a Web site, and an automated process kicks off that makes it happen. Nobody sits and monitors it or even pays much attention to it -- it's automated.
That kind of functionality is where "private cloud" got its name. The idea is that your own datacenter (if we're still allowed to call it "datacenter") exhibits those cloud-like behaviors. Marketing needs a Web site? Fine -- it'll push a button, and a requisition gets approved, and lo, there is a Web site. IT doesn't get involved. We built the tool that made it happen once all the right approvals were in place, but we didn't click the individual buttons to set up the VM and the Web site, or whatever. We automated it, using tools like System Center, PowerShell or whatever.
But I hate the term "private cloud." I really do. I much prefer the term utility.
When your organization needs a new fax phone line, you go through some internal business process to obtain the necessary authorization. The phone company isn't involved in that. Once you have approval to pay the bill, you tell the phone company to spin up the line. More often than not, someone on their end pushes a button and lo, a fax line is born. They didn't walk out into the Central Office and manually connect wires together -- that's so 1980. It's all automated, and it "just works." It's a utility.
And that's what IT needs to become. We stay out of the business process. We stop being the gatekeepers for IT services. We stop manually implementing those services. Someone wants something, they get approval and push a button. We just make the buttons do something.
And this is why the private cloud means you're going to lose your job…
Is it evolve or die for the Microsoft IT admin? Don Jones will give you his assessment in his final installment of the Microsoft IT Winds of Change blog series.
Posted by Don Jones on 03/25/2013 at 10:19 AM5 comments
Things are changing in the Microsoft IT world. It's happening slowly, but it's happening. We've reached an inflection point, or are reaching it soon -- and whether or not today's IT administrators continue to have a job (or at least, the same job) is very much in question.
Getting Nostalgic for Microsoft IT Administration
Do you remember Windows 3.1? Not a bad OS for a home user, and a pretty decent OS for a lot of smaller business people. Well, technically not an OS, I suppose -- it was really an operating environment layered over MS-DOS. But it was easy to use, and a lot of people got pretty good at using it. Ah, Program Manager. I miss ya.
What about Windows NT 3.1 and Windows NT 3.51? Those were Microsoft's first credible attempt at a full-scale, business-class operating system. And with them, Microsoft did something pretty clever: unlike the main network operating systems of the day -- think NetWare, VINES, and Unix -- Windows NT was easy to operate and administer. Heck, it looked just like Windows 3.1! You didn't have to memorize obscure commands. You could just click your way to a happy network. Every tool you needed came right in the box: a user manager, a server manager, DNS tools, even a rudimentary Web server. All graphical, and all easy to use. Ah, Program Manager. I miss ya.
That ease-of-use eventually got Microsoft in the door of corporations large and small. As a departmental file server, it was easy to set up and deploy without having to go to the IT department and their big, bad Unix boxes or hardworking Novell servers. And Microsoft built on its success: Exchange Server 4.0 offered a point-and-click, easy-to-administer alternative to cc:Mail and even the old Microsoft Mail. SQL Server came with every tool you needed to run an RDBMS, right in the box. That was Microsoft's pattern: make it easy, and include everything you might need right in the box.
This was an inflection point in the IT world. Suddenly, you didn't need to be an "IT monk." Normal, ordinary people could be IT admins, and hordes or normal, ordinary people took the jump. The release of NT 4.0 with it's Win95-a-like "Chicago" GUI, along with the heavily-promoted MCSE and MCSA certifications of the day, saw all kinds of people changing careers into IT. After all... it was easy!
In the IT Universe, Nostalgia Is BS
If Microsoft got its "foot in the door" by making its products easy to set up, easy to administer, and easy to use -- and by including every tool you needed right in the box -- then that's also where Microsoft set itself up for eventual failure.
First of all, not every tool you needed was right in the box. Plenty of organizations ran up against limitations and inefficiencies, and either ponied up for supplemental tools or just decided to scrape by with the native administration tools.
Second of all, "easy" also means "one size fits all." That is, a product can only lack complexity if it isn't very flexible. Organizations quickly started realizing that, and Microsoft responded by building in more flexibility. The problem is, flexibility always comes with complexity. If you can do something only one way, there's no need to make a decision, consider criteria, or anything – you just do the one thing the one way. As soon as you start having options, you have to decide what to do. You have to weigh pros and cons, decide what option is right for you, and then actually implement that option.
And of course Microsoft still had to actually ship products. Think about that: the OS and their various server products (Exchange, SQL, etc) are now more complex, and offer more options, so they obviously take longer to physically code. That leaves less time for coding tools. And so while the products became more flexible and capable, the tools didn't often keep up. Microsoft started focusing less and less on providing great tools, and instead focused on providing a great platform, upon which other people could build the specific tools a given organization might need. Ever try to pass a SOX audit using the built-in auditing and reporting tools? Exactly.
And this paved the way for the new inflection point, which would be almost the opposite of the last...
Look for Don Jones' assessment of what will make up a future Microsoft IT administrator in the next blog post.
More on this topic:
Posted by Don Jones on 03/22/2013 at 10:21 AM1 comments
A lot of organizations have a "run book" – a binder full of step-by-step instructions for accomplishing nearly every major IT task they perform. In fact, the term run book automation, as implemented by products like System Center Orchestrator, are designed to help automate those tasks.
First Point
As a decision maker in your IT organization, if you don't have a run book, start one. Right now. Make your team document every single thing it does. In detail. First, you'll help preserve institutional memory; second, you'll set yourself up to automate those tasks some day.
Tip: Make it a physical book. Electronic documents are fine so long as the electronics are working, but if something goes offline you'll want your run book to walk you through bringing it back online.
Second Point
Make it a picture book. The simple fact is that, when you need your run book it's because the person who's memorized a given procedure is unavailable, or because the proverbial fit has hit the shan. In either case, you want a clear, easy-to-follow set of directions. Like a picture book. As you create your run book, document each step of each task by using screen shots, not just words, so that the run book is as easy to follow as possible when need arises.
And then start focusing on automating those tasks using an appropriate tool (like Orchestrator, if that works for you). Performing tasks should be as easy as picking the task and clicking "do it."
Posted by Don Jones on 02/28/2013 at 3:59 PM0 comments
With the release of Windows 8 to MSDN and TechNet subscribers worldwide, we're starting to see more and more people setting up their first machines using the final OS code -- and starting to see more questions about some specifics. Unfortunately, Microsoft hasn't been providing much in the way of answers at this point. For example, my colleague, Jason Helmick, contacted me after testing some of the Windows Activation features in Windows 8. I'm providing his narrative below, enhanced with some of my own discoveries and comments in [square brackets]. I'd love to hear your comments and findings, too -- please drop them into the comments area below. With that said, take it away Jason...
Q: I'm confused about the Windows 8 Enterprise/ Pro Activation.
A: The three download versions of Windows 8 can be somewhat confusing at first, until you realize the purpose for each one. Lack of documentation in this initial stage of release has had more than one person download all three just to see which one they can license.
In my case (TechNet key in hand) I ended up downloading all three to see which one would take the key. The answer is the standard download (not Pro or Enterprise) but after working with the Enterprise and Pro versions I ran into the new activation process and had some questions. Without having any documentation to explain the new activation process I did an initial test. I'm left with more questions than answers.
The Pro and Enterprise downloads are designed to receive their activation through a traditional KMS server or the new Active Directory Based activation (ADBA). The Enterprise version of Windows 8 still supports Multiple Activation Keys (MAK) if that's your preference.
[I'll note here that I was able to help Jason find the right download and confirm his observations. The TechNet "Windows 8 Professional VL" ISO image requires a volume license key and Active Directory, or KMS-based activation; the "Enterprise" ISO also requires on-network activation or a Multiple Activation Key, or MAK. The "plain" Windows 8 ISO will accept a Professional key and activate as Windows 8 Professional.]
So, without a KMS server or MAK available, I decided to test Windows 8 Enterprise to see if there had been changes to the activation process, and to test the time it took the OS to expire when not activated. I'm not a hacker, and I'm not trying to pirate software; I'm just trying to understand from an administrative deployment perspective what is going to happen if activation fails. Documentation for this seems elusive at best (or doesn't exist). Here are the questions that I had when starting my experiment:
- How long does it take before the desktop activation message appears?
- How many rearms can I perform?
- How long does it take between rearms until the next activation message?
Perfectly legitimate questions if you're deploying Windows 8. After all, we need to know what happens when things go wrong. What symptoms indicate an un-activated copy of Windows? What will users be telling the help desk they're seeing? What can we expect? Crucial concerns, and I was concerned about the differences between Windows 8 and Windows 7. Hopefully, I thought, they'd be identical.
However, the answers I started seeing my experiment weren't what I expected. Perhaps some documentation or feedback could help understand what's happening. Here are the results from my initial experiment. (I'll try more testing soon):
Action |
Result |
Lingering Question |
Changed the clock forward one year (Windows and BIOS) to force activation message. |
It did not attempt to activate nor did it display a desktop message. |
So, how are they determining when it's time to activate? |
I forced activation with the set-forward clock. |
Activation failed looking for KMS and again, no activation message. |
|
Reset clock |
n/a |
n/a |
Checked SLMGR/ dlv for information about activation period (time till activation) |
No time period listed, but was shocked to see 1000 rearms available. |
1000 rearms? I can rearm this product 1000 times? This seems like a lot. |
Tried a rearm – SLMGR /rearm |
999 rearms left |
I wonder if I can script this to decrement the counter to 0? |
I tried to script the rearm |
Must reboot after each rearm so I need to make a better script |
n/a |
I decided to leave the box alone to see when it would display the desktop activation required message. The current time was 8:30am |
The activation required message appeared almost exactly 24 hrs later. |
Ok, so the first activation message occurred in 24 hrs. I have a 999 rearms – Microsoft could not possibly want me to have 999 days without licensing the product. Could they? That's almost 3 years! |
Performed rearm and waited for next Activation message |
n/a |
n/a |
In the interim I parsed the logs for activation. |
While you can see events for the activation process, I was unable to find an event logged when the desktop message "Activation Required" occurred. |
Why isn't this logged? Such an event could be useful for monitoring computers for this problem. |
Activation required appeared on the desktop approximately 8 hours after I rearmed |
n/a |
This makes sense. The activation time is getting shorter, forcing a rearm sooner. That explains the high rearm count as it will get quickly used if the time continues to shorten. |
Rearmed the system |
Activation required appeared on the desktop approximately 4 hours after rearm |
Again, it seems that the time windows is closing. |
Rearmed the system |
Activations required appeared on the desktop approximately 2 hours after rearm |
The time window is definitely getting shorter. |
At this point I had to stop the initial test. I may have made errors in this test and I want to examine it further. However, it would be nice if Microsoft would explain it so I didn't have to perform new tests.
Here's the question that is bothering me the most, and what I'm going to script and test for next week: After all the rearms, will Enterprise stop working?
In all previous tests Windows 8 continued to work normally without removing functionality (at least as I could determine). I could join it to a domain, remove it from a domain, etc.
So, what happens when you reach the end?
[Thanks, Jason.
This definitely seems to be a new twist on the old activation strategies used by Microsoft. Granted, the Enterprise edition is meant for… well, enterprise use, so it's nice to see generous terms and a shrinking activation window. It would still be nice to know how small that window can actually get (if it continues to divide by half, it's be down to nanoseconds pretty rapidly), and what happens if you reach the end.]
Posted by Don Jones on 10/24/2012 at 10:13 AM16 comments
Editor's Note:
This blog post was written prior to the news that Microsoft's new interface would not be called "Metro." All references to "Metro" were left intact for clarity.
Microsoft may have really messed up with their Windows 8 strategy. Its first big mistake was releasing community previews of the new OS, while barring most employees from talking about it or even admitting to its obvious existence. Release code without being able to explain it? Bad move. What messaging we did get was preliminary and off-base... and the company may pay for that. Here's what they should have told us.
It Isn't a "Metro Desktop"
The most controversial feature of Windows 8 is the so-called "Metro Desktop," a term that Microsoft never should have let pass without comment. Metro was never intended as a noun; it's an adjective, as in "the desktop with the Metro styling." And it isn't a desktop at all, obviously -- it's a dashboard, an evolution of the gadget-laden Sidebar of Windows Vista, and very close in functionality to the Dashboard view in Apple's Mac OS X. It's actually a better implementation than Apple's, because its tiles are more organized, and it also serves as an application launcher -- something Mac OS X distributes across a file folder, the LaunchPad view, and some other mechanisms.
In other words, the Metro-styled Start screen is a great idea. Its bad rep comes almost entirely from Microsoft refusing to speak about it for so long, and then not talking about it very well when they did ungag. Sure, there are some heavy restrictions on the apps that can run on this Start screen, but it's mainly made as a dashboard -- think lightweight gadgets, not full applications.
What's ironic is that the new Start screen is designed mainly to be touch-friendly -- something that's also been controversial, as the thing is practically unusable with just a mouse. Add in some keyboard shortcuts, though, and it's very slick. Start typing application names and up they pop. Hit "Windows+I" for the sidebar menu thing that took me forever to find with my mouse. Eventually, when we start using Apple-esque multi-touch trackpads with our computers (not just laptops), I suspect the new Start screen will be even nicer.
Microsoft just didn't get out in front of this one fast enough. It reminds me of the first ads I saw for Vista, which focused exclusively on the stupid "flip 3D" application-switching feature. Microsoft buried the headline there, focusing on something trivial and not communicating very well on what made Vista different. Microsoft's made that same error with the new Start screen, and the world in general has crucified them for it.
It's Business-Friendly
Windows 8 comes across as a consumer release -- so much so that a lot of businesses are disregarding it out of hand. Again, that's because Microsoft is burying the headline. In proclaiming Windows 8 as touch-friendly, etc. etc. etc., it's forgetting that 99.9999 percent of its customer base
doesn't use touch-based devices. But listen to the messaging coming out of Redmond and you could easily imagine that Windows 8 just isn't something businesses need to care about.
Au contraire.
Windows 8's deeper integration with the improved DirectAccess is nothing short of brilliance. The ability to centrally manage VPN-like connection options for your users, who can simply double-click and connect, is awesome. DirectAccess finally works, is straightforward, and is something everyone should look into -- and Windows 8 really utilizes it best.
SMB 3.0, the new file-sharing protocol in Windows Server 2012, gets the best love from Windows 8. Automatic -- nay, automagic -- failover of load-balanced SMB shares means a whole new way to think about clustered file servers.
Oh, and three words: Windows To Go. Part and parcel of the enterprise edition of the product, it enables you to build a secured, encrypted (via BitLocker) corporate image of Windows 8 on a USB thumb drive. Users can pop that into any computer and get the corporate desktop right there -- and when they pop out the drive, the desktop goes away, leaving no traces on the machine. This is so cool I can barely even wrap my head around it -- yet it's a feature getting relatively little spotlight.
It's Just as Good as Windows 7
The deployment technologies, support processes, and almost all the rest of Windows 8 are astonishingly similar to Windows 7. I think, in their race to look as cool as Apple, Microsoft is making Windows 8 seem a lot more revolutionary than it is -- and I mean that in a very good way. Enterprises don't like revolution; we like
evolution. Small, incremental changes we can cope with. Just for once, I'd like Windows 7.1, 7.2, and 7.3 – and Windows 8 actually feels a lot like that. It certainly exhibits about the same level of change as you get going from Apple's OS 10.7 to 10.8 -- some major cosmetic overhaul, some new concepts, but the same basic stuff at the core.
I think you'll have no issues running Windows 8 alongside Windows 7, or even skipping 7 and going straight with 8 if that's where you are in your lifecycle. You need to get the heck off of XP, that's for sure.
Yeah, the new Metro-styled Start screen is going to throw some people for a bit of a loop, but so did the Start menu when Windows 95 was introduced. They'll adapt -- they'll just whine a bit because they haven't had to adapt to any major changes since 2002 when you deployed XP the first time. And yeah, the new Metro-styled experience isn't comprehensive -- you'll find yourself dumped out of the "Metro Desktop" and into "classic" applications more often than you want, especially when you start fiddling with Control Panel stuff. That's fine. It's not as elegant or complete as an experience as we might like, but it's perfectly functional. We -- and our users -- are going to grumble about something anyway, so it might as well be that, right?
Posted by Don Jones on 10/23/2012 at 10:18 AM187 comments
Microsoft has a problem. A marketing problem. That problem's name is Windows Server 2012.
You see, as an operating system, Windows is pretty dang robust already. There's not a lot that we need it to do that it doesn't do. So Windows Server 2012 doesn't come with a flash-bang set of features. There are no massive changes to AD. Printing is still printing. Clustering works fine. Sure, it's probably "the most secure version of Windows ever," but I don't think anyone's dumb enough to try and sell that line anymore.
This means a lot of organizations -- a lot of decision makers -- are going to look at Windows Server 2012, say "meh" and ignore it.
Bad move. Windows Server 2012's improvements aren't skin-deep -- they're geek-deep. They're critical, yet evolutionary changes that make this a more robust, more stable and infinitely more usable operating system.
SMB 3.0
Yeah, maybe it's really Server Message Blocks 2.2, but it should be 3.0, and I'm glad MS is positioning it that way. Massively re-structured, this is a SAN-quality protocol now, capable of moving close to 6 gigaBYTES per second. Yes, gigabytes, not the usual gigabit measurement of bandwidth. It's got built-in failover, too, meaning clustered file servers are now a no-brainer. It lets file servers scale out, too -- something which has never before been possible. There's a geek-speak explanation of all the new hotness in this Microsoft blog, and you gotta believe this is going to be a game-changer for the OS.
Dynamic Access Control
While this will be limited, initially, to the access controls on shared folders (rather than on files, AD or something else), this is showing us what the foundation for ACLs looks like in the future. Imagine complex ACE definitions like "must be a member of Admins, but NOT of HR, or can be a member of Execs" -- and that statement is evaluated on the fly. This truly enables claims-based access control, because it doesn't have to be built on user groups any more. "User must be in the department 'Sales' in AD, and must not be in the Denver office." Keep your AD attributes up to date and suddenly access control got easier -- and much more centralized. This will still layer atop existing NTFS access controls, as share permissions always have, but it's a big deal. Start wrapping your head around this now, because it's a model you'll see creeping further in future releases.
PowerShell
This is the version of Windows we were told six years ago was coming. Almost completely manageable via PowerShell (if not completely completely; it hasn't shipped as I'm writing this, so it's tough to say), this is the version of Windows that starts to deliver on the PowerShell promise: Automate Everything. Combined with PowerShell v3 foundation features like more robust Remoting, Workflow creation and more. Windows Server 2012 is taking a page from the Unix book and rewriting it for the Windows world. That's a good thing because it truly enables enterprise-class sensibility in our server OS.
Server Core
Explain it to me as many times as you want, and I'll never understand why folks RDP into a server to perform basic day-to-day management rather than just installing the GUI consoles on their admin workstation. But Win2012 raises the stakes, providing a "GUI-free" server console that doesn't have the limitations and caveats of the old Server Core installation mode. Take heed: Whether this excites you or not, it's Microsoft's direction. Start thinking about managing your servers from your clients, because that's going to be the only option in the not-too-distant future. Oh, and as for installing all of those admin consoles on your client? Maybe not: PowerShell Remoting means the admin tools can "live" in the server, but "present" on your client.
Get You Some Win 2012
"The right tool for the right job" is the mantra all of IT should live by, and Win 2012 is shaping up to be a better tool for many jobs. It's worth looking at. Even if you think your organization won't have any 2012 goodness well into 2014, at least familiarizing yourself with the tool's capabilities will put you in the driver's seat. You'll be prepared to help make recommendations about this new OS, speak knowledgably about its capabilities (and about what it can't yet do) and be the one to lead its adoption and deployment. Better to be driving the bus than to be run down by it, eh?
Posted by Don Jones on 06/22/2012 at 9:53 AM8 comments
I'm sure you've seen endless analysis and opinion about Microsoft's re-re-revamped certification program, so I'll avoid adding any more to the pile. However, I do want to ask some questions -- because ultimately the value of these certifications comes from decision makers in organizations. If the boss cares, then the employees care, HR cares, and so forth.
First, one minor bit of opinion: "MCSE for Private Cloud" does, I have to admit, make me puke in my mouth. Just a tiny bit. I'm so sick of the "C" word, and this certification -- simply some Windows Server 2008 exams added to a couple of System Center 2012 exams -- seems to be no "cloudier" than a nice day in Phoenix. But whatever. The marketing people probably could help themselves.
Microsoft's new certification program stacks into three tiers: The Associate level, the Expert level, and the Master level. These each break into two categories: "Certifications" and "Cloud-Built Certifications" (deep breath, hold, out the nose).
So... do you care?
In the beginning, these certification programs -- and I'm talking Windows NT 3-era here -- were largely a play by Microsoft to say, "Look, there are tons of people who can support our products, so why doesn't your business just send us a check for some software, hmmm?" Microsoft's certifications, like most IT certifications, have never been an attempt to protect businesses, to protect the public, and so on -- not in the way other professional certifications, like those in the medical or legal industries, are intended to do (whether they do it or not is, I'm sure, debatable).
So does the large body of Microsoft-certified human beings make you sleep more easily at night?
Do you find that a Microsoft certification acts as anything more than a bare-minimum filter for HR to hone in on when sorting through incoming resumes?
Knowing all about the "paper MCSE" syndrome, the scores of brain-dump Web sites, the certification cheats and all of that, would you still rather hire a certified individual over a non-certified one?
Would you discard, out of hand, the resume of someone claiming eight years of IT experience who doesn't have a certification over someone with less experience who does have a Microsoft title?
If you were to offer some advice to an IT person who doesn't have a certification but who's worked in a lower-tier IT position for a year or so, would you advise them to the exams needed to earn the new MCSE, MCSA or whatever? Or not? Why?
In short, how does Microsoft's certification program affect your business? I'm genuinely curious, and I'd love your comments. Drop 'em in the box below.
Posted by Don Jones on 06/05/2012 at 10:43 AM25 comments
I've given up on being frustrated and annoyed with the IT marketing industry's profligate use of the word "cloud." I now am a happy user of cloud mail (formerly "Outlook Web App"), cloud storage (formerly "FTP server"), cloud computing (formerly "hosted virtual machine") and cloud services (formerly "Web site"). My last point of resistance -- the "private cloud" -- has been whittled away by the incessant efforts of Microsoft and other vendors' marketing machines.
Fine. Private cloud it is.
There's actually an emerging definition for what that means, and how it is distinct from what we used to call "datacenter."
- Automated provisioning. When you spin up a new Amazon EC2 virtual machine, you don't have to call someone on the phone or file a support ticket. Heaven forfend -- the idea of engaging a human being in the process is anathema to Amazon's entire business model. No, you click a few buttons, you type in your credit card number and a virtual machine is born. In the private cloud, this simply means automation -- something Microsoft is making excellent strides with through its growing integration of PowerShell. This is a good benefit for organizations because it helps reduce error and improve business agility, lower response times and alleviate plain old administrator fatigue.
- Pay as you go. Another excellent analogy that uses Amazon EC2: You pay for what you use. Now, in the private cloud we perhaps don't need to be as nitpicky as to get down to the compute cycle, disk block, RAM usage and bandwidth utilization -- but certainly the idea of internal charge-backs isn't new. The main reason IT hasn't done charge-backs on everything to this point is that we haven't had the tools to do so. Anyone promising to help you implement "the private cloud" needs to make charge-backs easy -- and some vendors like IBM and HP are actually doing just that. Allocating the costs of IT to its actual consumers is beneficial, even if the company doesn't do the funny-money internal transfer of numbers. Simply knowing, rather than guess, where your costs are going is a good thing.
- Abstracted. This is a big deal. I buy an Amazon EC2 virtual machine, I have no idea what physical host it runs on. I don't care. Amazon can shift it around all day to balance their workload, and that's fine with me. Ditto the private cloud: Ubiquitous hypervisor availability lets us treat server hardware as Giant Pots O' Resources, and we shift VMs around to suit our needs and whims. Again, a good thing. Server hardware lasts longer (old servers can just run less-needy VMs) and we can start to think of our datacenters in terms of capacity rather than of functionality.
So will your entire datacenter become one fluffy white private cloud? Doubtful. But pieces can. Whatever pieces are frequently requested by, and granted to, individuals or departments; VMs for software developers to test with, VMs for department or project file servers, you name it. Heck, with the right front-end, you could make some of those things entirely self-service. Why not let devs spin up their own VMs based perhaps on predefined, easy-to-select templates when they need to test something? It's basically the premise of commercial ventures like CloudShare.com, and there's no reason you couldn't offer it as part of your private cloud.
Plus, you'd get to use the phrase private cloud a lot. And it's a hip phrase, so everything would have to pretend you were cool.
There's another bonus to cloud-ifying the right bits of your datacenter: mobility. Suddenly decide that you don't want to own some particular piece of functionality? Find a way to outsource it more cheaply? Fine -- you've already abstracted the important bits away from the users, so does it matter that a bit of "your" cloud lives in to own some particular piece of functionality? Find a way to outsource it more cheaply? Fine -- you've already abstracted the important bits away from the users, so it doesn't matter if that bit of "your" cloud lives in your datacenter or not.
What's this do for your IT team? Well, if I were an IT person who'd taken the initiative to learn automation techniques and technologies -- say, PowerShell or something like it -- I'd be sittin' pretty. I'd be building the private cloud (the cloudy bits, anyway), and I'd be a key player in the organization. If, on the other hand, my main job in IT was clicking the buttons that are about to stop existing in favor of better automation, I'd be against the cloud. In any form. Which is certainly why some IT pros (not all, just some) are against the cloud -- they fear for their jobs.
So be prepared. Build the cloud and you'll have a job for the next decade or two. Get run over by the cloud (see, they're not always so fluffy) and you obviously weren't planning ahead. I'm a bet-hedger, so even if this whole private cloud thing is a bust (and it won't be -- the business reasons for an intelligently built datacenter to become at least partly cloudy are too compelling), I'm spending the time to make sure I'm up to speed on the enabling technologies: Automation. Virtualization. Systems management. Because when the cloud does come, I want to be sitting on Number 9, not huddled in a rainstorm.
Posted by Don Jones on 05/24/2012 at 11:16 AM0 comments
I'm seeing a worrying trend in the world of Microsoft IT. Let's politely call it the "head in the sand" phenomenon. My theory is that it comes from such a long period -- around a decade, really -- of relatively few major OS-level changes, especially in the Server version of Windows. Not that Windows 2008 didn't feature improvements over 2003, or that R2 didn't improve upon that, but they were largely incremental changes. They were easy to understand, easy to incorporate, or if they didn't interest you, easy to ignore.
That's not the case with Windows Server 2012, and I'm worried because I'm not seeing IT decision makers and IT teams really engaged with what's coming. The "oh, we're not moving to 2012" argument doesn't hold a lot of water with me because you never know. It's easy to have one or two servers creep in, often to support some other need, and before long you've got a lot of 'em.
Specifically, I'm worried about the lack of attention being paid to WS-MAN.
WS-MAN: Not Just for PowerShell
WS-MAN is the protocol that underlies PowerShell Remoting, and it's been available for Windows XP, Windows Vista, Windows 7, Windows Server 2008, Windows Server 2003 and Windows Server 2008 R2 for a few years now. I think many IT shops have felt comfortable ignoring it because it didn't push itself on you. If you wanted it, you learned about it before using it; if you didn't want it, you just ignored it.
That goes away for Windows Server 2012. It enables PowerShell Remoting -- and thus WS-MAN -- by default, because it needs it. Server Manager, you see, has been rebuilt to run on top of PowerShell. And even if you open Server Manager right on the server console, it still needs Remoting to "talk to itself" and make configuration changes. That pattern will grow more and more common as Microsoft starts shifting management tools to PowerShell. In earnest, Remoting makes it much easier for developers to create rich GUIs, built on PowerShell, that manage remote servers. By not distinguishing between "local" and "remote," developers ensure a consistent experience either way -- and help enable headless servers, a direction in which Microsoft is most assuredly heading.
So the idea of, "well, we don't use Remoting, so we'll shut it off" doesn't work anymore --it'd be as effective to just shut of Ethernet. You can't manage new servers without it -- so it's time to start focusing on understanding WS-MAN, and creating a place for it in your environment. Now, while you've got time to plan, rather than later when it's a forgone conclusion and it's just snuck its way -- uncontrolled and unmanaged -- into your environment.
Learning WS-MAN
Start by reading "Secrets of PowerShell Remoting," a free guide I put together with the help of fellow MVP Tobias Weltner. There's even an entire chapter on WS-MAN's security architecture, and answers to common security-related questions.
Practice setting up Remoting on your existing machines, even in a lab, so that you can become familiar with it. After all, if Win2012 is going to make you use Remoting, you might as well take advantage of it for other servers too -- and reduce your management overhead.
Don't think of WS-MAN as another protocol to deal with -- think of it as enabling fewer protocols, as it starts to phase out Remote Procedure Calls (RPCs) and the other scattershot protocols that Windows has relied upon for years.
Will there be security concerns about WS-MAN? Assuredly. Interestingly, many of the questions and concerns I've heard raised have has substantially poorer answers when it comes to our existing management protocols. When it comes to WS-MAN, people ask about the security of credentials, the privacy of the communications, and so on -- but I've never heard those questions raised about RPCs, which is what's mainly running your network right now. Keep that in mind, it's completely reasonable to ask the hard questions, but don't set a bar for security that you've never, ever met before, without at least acknowledging that you're doing so.
And keep in mind that WS-MAN isn't optional. I've had folks tell me that their "IT security will never allow it." Doesn't matter what IT security thinks: This thing is coming and it's mandatory for server management. Wrap your head around it now or later – although "now" will let you learn the protocol and make it a welcomed part of your environment.
Is Microsoft Crazy?
Maybe. Have you seen Ballmer jumping around at conferences? That's crazy. But more to the point, is Microsoft crazy in introducing a new management protocol that supports encryption, compression, delegated authentication, secure delegation of credentials, mutual authentication and that only requires a single HTTP(S) port rather than entire ranges?
Um... doesn't sound crazy.
Is Microsoft crazy for replacing a set of 20-year-old protocols with something newer, more manageable and more extensible? Yes -- in much the same way that replacing MS-DOS with Windows was crazy.
I'm not here to justify what MS is doing with the product; that's up to MS. I'm here to help people understand where they're going, so that we can be prepared. You don't have to like it, or agree with it, but you will have to deal with it. Better, I think, to start understanding it now than to wait until it's snuck in and is an uncontrolled part of the environment.
Posted by Don Jones on 05/14/2012 at 12:18 PM6 comments
You have to be pretty careful in trying to draw conclusions from our little survey, because we deliberately didn't look at some of the things which absolutely impact an organization's ability to succeed with IT. We didn't look at managerial experience. We ignored their operating system choices and other vendor decisions. We ignored important things like time-in-profession for top-tier IT staffers. We thought those were all pretty obvious in terms of tactics to achieve success; we were looking for less obvious markers.
If we had to put our finger on one major success precursor, it's hiring. Should be obvious, but we think most organizations do a terrible job of hiring, and that the labor pool simply doesn't supply enough good candidates in all the right places.
We'd also say that a culture of support was in evidence within our successful companies. Administrators got the tools they needed, instead of being asked to do everything manually -- but had no hesitation to hack out something home-grown if that was the only way to get the job done. "I am doing this manually, once, and never again," was such a clear, consistent and resounding sentiment that we can't help but feel it must have some positive impact on those organizations. Employees in successful organizations seemed to feel -- and we hate using this word, but here it is, straight from Oprah -- empowered. They knew what needed to be done, and didn't have to fuss around much to get it done.
We definitely saw more successful organizations having more flexible policies and processes, but we think that's pretty obvious, too. There's a very fine line between using processes to control and manage change, and using them as a blunt weapon to slow things down and make people miserable. Some managers are better at walking that line than others, and it does seem to correlate to a more successful IT team -- but not as strongly as some of the other correlations we observed.
So, your thoughts? Are you in a successful IT organization? If not, what's the problem? If so, what's your secret?
Read the rest of this blog series here:
Posted by Don Jones on 05/07/2012 at 9:40 AM0 comments
What was really interesting is a total lack of correlation in the one place we expected it most: salary. The staffers in our successful organizations were not necessarily the most highly paid folks we looked at -- they were almost always hovering right around the mean. Money is clearly important to retaining the right people, but you can't necessarily spend more to get better people. You have to get great people and then pay them what they need.
We also saw no correlation around the topic of certifications. Some organizations cared, some didn't; some employees cared, others didn't. It didn't seem to matter, as these attitudes were evenly spread throughout all of the organizations we looked at, including both successful and unsuccessful ones.
We also didn't see correlation in Human Resources practices. As nota big fans of HR ourselves (we were all independent contractors, so it's to be expected), we thought the successful organizations would be the ones that kept HR out of the way. Not necessarily; some of our more successful organizations (again, by the metrics we calculated) set aside up to 10 percent of their employees' time for HR duties like reviews, goal and commitment development (and other tasks).
Budgets didn't seem to be a correlating factor, either. We looked at the overall IT budget, adjusted it for the size of the organization and found that it didn't matter how much you spent per person on IT -- you didn't necessarily get better results. While it's true that we saw more tools in use within successful organizations, so things like software spend would be higher, we also saw more use of self-service and other cost-reducing measures which probably helped offset that additional spend.
We did not see -- and this really surprised us -- a lack of religious fervor within IT. Some organizations were passionate about Windows, others about Unix, and they could be perfectly successful while maintaining that fealty. Certainly, some successful organizations had a little bit of everything, but the striving for homogeneous technology didn't seem to hurt.
We also didn't see an emphasis on cross-training or matrix management. Some of the most successful organizations we looked at were built with incredibly strict disciplinary silos (I'm the Unix guy, you're the database guy, you're the C# guy, etc.); so long as they maintained an appropriate level of cooperation between teams, it didn't seem to hold them back from being incredibly successful.
Read the rest of this blog series here:
Posted by Don Jones on 05/01/2012 at 9:38 AM0 comments
Having figured out how our survey organizations define success, we needed to look and see what else we could tell about those organizations. Our goal was not necessarily to figure out how they were successful, and that's something important to keep in mind as you read. Correlation does not always equal causation, and we were mainly looking at correlation here: Observed characteristics of an organization that just so happens to be successful under our metrics. We specifically tried to avoid cracking into how these organizations achieved their success; we wanted instead to look at the less-visible things that helped to organically support that success. Here are some of the major things we noticed:
- Automation is endemic to the culture. People in successful organizations do not run graphical wizards for anything they need to do more than once; they find a way to automate it. Sometimes, those ways are hack-y and ugly, but they're there.
- Any problem, which has occurred more than twice, has a documented response plan and, when possible, an automated first-response plan. Frankly, we'd expected this to be "more than once," but there appears to be a bit of tolerance overall.
- There are concrete criteria around performance, and these are often communicated to and visible by end users. In many cases, these are intranet-based "dashboards" that display rolled-up performance data (think simplistic meters). Users understand not to complain about anything that's "in the green," and know that anything else is already under alert and being looked at.
- There's remarkably little "throw it over the wall" with tickets. Tickets get escalated only when it's absolutely necessary; higher tiers handle the problem and tend to never drop things back to a lower tier. Getting back to the automation bit, we saw higher-tier people solve problems in ways that could then be handed off to lower tiers, or turned into self-service solutions. The general feeling in this organizations is, "I'm only going to fix this once, and it'll be fixable by other people from then on."
- Nobody goes into the datacenter unless they're repairing broken hardware or installing new hardware. Period. We were actually surprised at the degree to which this held true. Data centers were literally "lights out" almost all the time.
- Above the first tier, where this varied quite a lot, we saw a lot of consistency around training. Most IT staffers got two to three classes per year on top of a conference, and they self-selected almost all of that based on their interests and where they felt their skills needed supplementing.
- Tools were in use. Our successful organizations utilized something like three to four times as many third-party support tools as less-successful ones, and utilized something like 10 times as many home-grown tools (which plays back to the automation thing, in large part).
Interestingly, we saw little formal structure to make any of these behaviors happen. People's job descriptions never mentioned automation. There were no long, complex processes detailing how to handle every possible situation. In many cases, we didn't even observe a managerial mandate to document problems. We simply had to conclude that these organizations had kick-butt IT employees who just wanted to do a good job. Management certainly supported that, and likely drove it to some degree, but having enthusiastic employees who want to do a great job is clearly important.
We also noticed that about two-thirds of our "successful" organizations had a remarkably lower management-to-staffer ratio than other "successful" organizations, and that ratio was also lower than most "unsuccessful" organizations. We saw ratios like 1:20, which flies in the face of a lot of management theory (this was direct reports to their immediate manager; we didn't look at middle tiers). Again, this is correlation, not causation, and we certainly saw a third of our successful organizations with more traditional ratios of 1:5, 1:8, and so forth.
Read the rest of this blog series here:
Posted by Don Jones on 04/22/2012 at 9:36 AM1 comments
For years, analysts have put forward models of IT maturity -- even major vendors like Microsoft got into the game. Basic. Proactive. Agile. Remember agile? Some big, big companies got behind that word.
I recently worked with a group of consultants who completed a 300-company survey of IT maturity. Rather than trying to apply fancy terms to different levels of maturity, we focused on two things: What do companies want from IT, and of those companies who are getting it, what are some of their other characteristics? In other words, what does a successful IT team look like?
I'll present our findings in several parts; what you'll read is essentially a summary of everything we learned. Keep in mind that we didn't actually make anything up for this -- we simply surveyed companies to define success, and then observed companies who were, by that criteria, the most successful in IT. You're welcome to contact me if you or your organization would like to learn more about our findings.
What Does a Successful IT Organization Look Like?
This was obviously the first and most important part of the study: What does a successful IT organization look like? We started at a fairly high business level with executive statements revolving around delivery and overhead, but then took those and started to drill into specific numbers. Mind you, most of the companies we spoke with were not successful according to their own criteria; we based our final findings on statistical averages and means across what every company told us. We then tried to abstract the numbers just a bit so that they could potentially apply to every organization, not just ones of a certain size. Finally, we re-scaled the numbers to make sure that what we were seeing in terms of criteria truly did match back to what companies told us, once we adjusted for company size.
So here's what we're told a successful IT organization looks like:
- The organization's highest-paid (what most people would call Tier 3) staff spends less than 10 percent of their time on break/fix problems, approximately 20 percent of their time training and mentoring lower-tier staff, and the remainder of their time on design and implementation of new projects and of upgrades.
- No single help request topic handled by the organization's Tier 1 support (what most people call the help desk) staff comprises more than 20 percent of that tier's total workload. In other words, there are no major recurring problems that can't be solved through self-service solutions. Password resets, for example, will never go away, but they shouldn't occupy people's time.
- Most problems are solved from documentation or knowledge bases, even when the fix must be implemented by IT staff and not an end user. Specifically, less than 5 percent of the fix-time for most problems is spent on research and information-gathering. This was a tough number to ferret out, as few orgs track resolution times with this kind of detail, but we conducted a few interviews that seem to all point to roughly this number. "Most problems" turns out to be something like 90 percent, meaning about 10 percent of problems took longer to research.
- Unplanned downtime -- and this could be an entire system or an entire user -- compromises less than 1 percent of the organization's total time. That is, no one user is down for more than 1 percent of their workday, no one system is down for more than 1 percent of its service period, and so on.
- Fewer than 10 percent of trouble tickets relate to the performance of production systems. In other words, either users perceive performance to be fine, or they've been educated (often via SLAs) on the difference between "good" and "bad" performance, and don't call in when they know things are in the "good" range.
- Tickets tended to be fixed in more or less the shortest time possible for the problem at hand. In other words, we observed very little "procedural overhead" around IT. If a user called and needed access to some folder, and had permission from the data owner (the means by which that permission was communicated and evidenced varied a lot), then the problem was fixed in minutes, not days.
Those are the main points. Not surprisingly, they all revolve around downtime and fixes. True, most IT organizations do a heck of a lot more than just fix problems, but problems are obviously pretty high-profile within an organization, and so they tend to drive perception of success or failure. These "issue-based metrics" were interesting to us, because they reflect an organization's definition of success once the SLAs have failed. That is, teams already have SLAs in place for routine things like creating new mailboxes; the metrics we've outlined are for how well things are handled once the SLA isn't met.
Our next step was to start looking at other, more detailed behaviors within organizations that were meeting this criteria.
Read the rest of this blog series here:
Posted by Don Jones on 04/09/2012 at 9:34 AM0 comments
We're accustomed to thinking of IT as "white collar" positions -- office jobs with little or no manual labor. But I've started revisiting that presumption in recent customer engagements. Many of my customers' IT decision makers are struggling to motivate their team, to update their skills and to get critical projects underway -- and sometimes, a portion of that struggle comes from not appropriately understanding/managing "blue collar" and "white collar" employees.
So what's the difference?
First, I'm not making a value judgment between "white collar" and "blue collar." I'm not presenting one as more valuable or more desirable than the other. But there are certain characteristics associated with both -- and both offer pros and cons to the organization. Understanding what your team consists of is crucial to motivating them, and to getting the most from those resources. In some cases, you may find that you have "white collar" expectations, but that you're treating your team like "blue collar" workers -- meaning the disconnect between what you want and what you get is at least partially your fault as a leader.
The following table summarizes some of the key, observable traits for each type of employee. Note that these are pretty atomic -- you can't pick and choose from Column A and Column B. These all tend to go together, so getting the results you want means making sure a given employee can line up completely in one column or the other. In other words, if you're providing the resources a "blue collar" person would need, don't act surprised when they don't exhibit the behavior of a "white collar" colleague!
WHITE COLLAR |
BLUE COLLAR |
Goes to trade conferences |
Doesn't go to trade conferences |
Regularly receives training to update and expand skills; training is as likely to be aligned with long-term career development as with immediate project needs |
Doesn't receive training as regularly; training may be more aligned with immediate projects than with long-term development |
Is passionate about what they do -- often has hobbies that relate to their job |
Is less passionate about the job per se; may still love tech, but doesn't have hobbies that mirror their work |
Constantly looks for, and suggests, ways to improve processes, tools and products |
Less likely to suggest improvements; may primarily suggest improvements that reduce their own work effort |
Wants to learn new technology often for the sake of knowing it |
Less interested in learning new work-related technologies unless there's a specific and immediate production requirement to do so |
Maintains an updated resume, even when they're not looking for a job or promotion |
Tends to update the resume only when it's time to go job-hunting, or when a promotion is available |
Steps up quickly when new, strategic skills are needed -- and may in fact already be up on what the organization needs |
Usually willing to learn new skills, but only because you've asked them to -- tends to be a bit less initiative when it comes to breadth of knowledge outside the scope of their job |
I'll acknowledge that the terms "white collar" and "blue collar" are pretty loaded, so I'll tell you how I've been thinking of them.
White collar, to me, is someone who has a career. Maybe they won't always be with the same company, but they'll always be doing the same type of job -- and they want to invest in it. They're concerned about the state of their resume, and always looking to improve it -- even if some skill they see as important isn't something their current employer needs. They maintain a resume, even for internal promotion purposes.
Blue collar, by contrast, is someone who has a job. Maybe they haven't been doing IT all their lives, and maybe they don't plan on doing it for the rest of their working lives. It's a job, hopefully one they enjoy, but it's just a job. They're not in love with it. Learning new skills to support some production requirement is fine, but they're not going to run around randomly learning stuff just for the sake of doing so.
Neither categories in any way implies a better employee. Some job positions are, by their nature, one or the other; other job positions could be filled by someone with either attitude. This isn't about how productive someone is, how dedicated they are or how hard they work. This is about underlying attitudes on the part of both employee and employer.
You see how this goes? If you've got folks who seem to just not care, who just want to do their job and then go home and play Xbox -- well, look and see if they're being treated like a blue-collar worker. Are you investing in their skills? Are they passionate about what they do? Are you treating them like a career resource or a replaceable cog in the machine? You can't dish out blue-collar treatment and expect white-collar behavior.
As with all stories, there are two sides. For some folks in IT, it's just a job. They don't understand why you'd expect it to be anything else. They don't do it because they can't help doing it; they do IT because it allows them to support their families and lifestyle. That's "blue collar," and there's nothing in the world wrong with it -- so long as you and your employees both agree on what you expect from them.
It could also be that you've got passionate, career-minded people on your staff who just act like they don't care -- because they're not feeling the love from you. A career is a long-term thing; to get in the career mindset, you've got to be willing to invest in that career yourself. That means sending folks to conferences, to training classes and so on --and not just so they can learn a new skill that supports and immediate production requirement. That's not investing, it's responding to a need.
There are pros and cons, as I've said, to either category of worker. White collar workers are often at the lead of new projects because they've been building the necessary skills and knowledge on their own time. Having them means you can move more quickly, and leverage skills that, technically, you haven't paid for yet. But white collar workers require more maintenance, and can be higher-overhead. Blue collar workers are the dedicated, get-it-done folks who work hard and don't always demand as much from their employer -- but don't be upset when they haven't been studying up on new technologies on their own time, just so they can be ready when and if you suddenly need them.
In reality, most employers will want a good mix of attitudes in their environment -- and will provide the right mix of benefits, investment and support to create and nurture both those attitudes.
Posted by Don Jones on 03/23/2012 at 4:05 PM1 comments