Proverb: Assume you will fail. Plan around it.
This article on CIO.com says it all: “So Long IT Specialist, Hello Full-Stack Engineer.” Business are realizing that they can’t have It people who only know one thing. They need IT people who can do it all – engineering, maintenance, troubleshooting, and coding.
No, not every single IT person will do every single job, especially in a large organization. You’ll specialize, to a degree, but that’s mainly be a job assignment thing. You’ll be expected to be able to pick up any task with just a little training or familiarization.
That’s going to depress the crap out of a lot of what Microsoft calls IT Pros, because they got into the business for entirely different reasons. They didn’t want to become programmers, and they still don’t. I used to have a lot of sympathy for that, and a lot of my teaching messaging tried to accommodate the fact that these folks kinda had the rug pulled out from under them.
Now I don’t care. This has been coming for a long time, and if you haven’t caught the memo it’s because you had your head int he sand, and willful ignorance is the one thing I can’t abide.
Let’s say you’re a younger, single guy. There’s a store not far from you where you buy your beer, your ramen noodles, and all the other stuff you need. Years pass, and you meet a nice girl. You get married, one thing leads to another, and now you’ve got a kid or two. Your needs have changed: you need diapers. Formula. Baby food. Valentine’s candy for your lady. If that store you used to shop at continues to meet your needs, you stick with them. If they don’t, you go somewhere else.
When it comes to IT, business’ needs are changing. They’re growing up. Things are moving faster, and they need to be able to deploy solutions, tools, and technologies more quickly. They can’t rely on the old silo model where developers went into a cave for a year, produced some code, and then “turned it over to ops” to deploy and maintain. Now, everyone’s got to be in the mix. “Admins” are expected to take up some of the coding tasks, so that “developers” can focus on specific bits. Developers are expected to produce code that’s designed to be operated and maintained, meaning they have to think a bit more about what operations does. In other words, the lines are getting fuzzy.
As business’ needs change, you – essentially a service provider to the business – need to adapt, or they’ll go elsewhere to shop. You don’t have to like it, because it’s your job, not your hobby. You don’t even have to do it – but don’t complain when the business decides to take its business elsewhere.
Learn a programming language, if you don’t know a couple already. Learn how to read PerfMon, if you’ve only ever been writing code. Adapt or die.
Proverb: Always promise what you can deliver. Always deliver what you promised.
Every been out on a boat? You’re supposed to wear a life jacket, right? You might not need it, but just in case.
Does your career have a life jacket?
That is, if you run into a day-to-day technical problem, to whom would you go to for help? Google? Online forums? That’s kind of like forgoing the life jacket and just hoping the dolphins will save you if something goes wrong. They might. It’s not impossible.
Or maybe you rely on your coworkers. That’s kind of like relying on the other people in the same boat, though, isn’t it? If the ship’s going down, it’s kinda every man for himself. I’ve always relied heavily on coworkers to make sure the job gets done, and they’ve relied on me; but when it comes to dealing with real problems, I’d like my safety net to be a little more expansive.
I find that software developers tend to grasp this concept pretty well. Most developers I know regard the entire software development industry as their “career,” regardless of what their current job might be. They actively participate in the broader community:
- They reliably respond to questions on forums. They spend a lot of time correcting each other, but that’s part of community, too.
- They attend conferences. They go to classes. They watch instruction videos. They really learn.
- They go to user group meetings. They do stuff after hours and on the weekends that’s development-related.
- They blog a lot. Even if it’s on something either other people have blogged on. For any given problem, you usually get a range of opinions on how to solve it.
- The complain a lot. Loudly, about things they don’t like in technology. This results in more fixes from vendors.
I don’t know why, but I find that fewer IT pros engage in some of the same behaviors. It’s tougher for us to get to conferences, I feel, because we’re often needed more from minute-to-minute than developers, who tend to work on projects more than “fires.” But I see fewer IT pros engaging in community.
Community isn’t just asking a question on a forum. It’s going back to that same forum later and seeing if you can offer any answers. Of all the various IT pro-focused forums I’ve engaged with over the years, fewer than .01% of the question-askers ever come back to offer answers, or an alternate approach, or an additional observation. Most just show up when they have a problem, and then vanish when it’s solved. But think about the advantages of coming back. You get to know the other people who post there. When you’re in real need, you can ping them in an e-mail and ask them to look at something a bit quicker than usual.
And this isn’t just forums. There are all kinds of ways to engage and become a part of community. Get on Twitter and watch relevant hash tags. Frequent some blogs, and comment on their articles. Attend a user group meeting – every time they have one. Heck, start a virtual, online user group around a specific topic. Attend a conference and actually network, instead of just soaking in all the education. Make personal connections. Get to know people. Those people will become your colleagues. They will support you when you need an answer, and they will recommend you when you need a job. They will offer suggestions when you need to find a solution, and they will be there when your current job isn’t.
If you don’t have connections then you do not have a career. You have a job. I’ve written before about the distinction, and I think it’s an important one. Yes, it can be difficult to begin, and it can be time-consuming to maintain. But having a career is a life jacket for when your job starts to sink. When your job has a fire, your career helps provide the extinguisher. If your job becomes vexing, your career helps offer the way out.
So consider spending the effort to get connected. Find colleagues, and keep in touch. Find ways to meet people virtually, if not in person. Form a network. Make a career.
My new Learn SQL Server Administration in a Month of Lunches, along with Jason Helmick’s Learn Windows IIS in a Month of Lunches and James Bannan’s Learn SCCM 2012 in a Month of Lunches will all be 50% off as “deals of the day” on February 14th, 2014. Hop on Manning.com and use code dotd021414au to claim your discount (you can access book pages directly by clicking their titles here).
The SQL Server and SCCM 2012 books are still in “preview mode,” meaning you’ll get access to the current manuscript as well as all updates through and including final publication. If you order the print/ebook combo, the print book will ship once it’s published. Ebooks include PDF, MOBI, and EPUB formats for all buyers.
Tell a friend!
Proverb: Don’t be f-ing lazy.
On February 11th, this is going in a band around my left calf (at least partially – not sure if it’ll be 2 appointments). Thought I’d geek out and share.
The first logo is a Jeep grill. This is actually partially done already; I have the grill and headlights from 15 or so years back. I’ll have those refreshed, and the outline added. Jeeps have been huge in my life – I’ve owned 3 Wranglers and a Cherokee since 1996, and they’ve been with me through some of the best and worst times. Having a Jeep around became a comfort, like a safety blanket, which is why this grill was the first tat I ever got.
Next up is Mickey. Disney’s been a big part of my life, and Disney Parks remain my go-to place to shut off and relax. I’ve had some of my best times there with my family, and they’re times I’ll remember forever.
Number three is the logo from my first real computer, a Commodore 64. I learned to program heavy-duty on that thing, helped run a BBS, and did my first writing for my local Commodore Users’ Group magazine. The C64 definitely put me on the path that led to my career.
In the middle of the back of my calf will be the F-14 Tomcat logo. It’s really a cool logo – like the aircraft, it has twin tails, and a gun. Why “Tom” cat? Naval Vice Admiral Thomas F. Connolly was influential in getting Congress to kill the failing F-111A project and instead fund a new fighter. The new fighter would be carrier-compatible, meaning it would launch by means of a steam-powered catapult. Such aircraft were often called “cats,” so the F-14 became known as “Tom’s Cat.” Tomcat (Manufacturer Grumman also liked using feline names for jets). As described on the “About” page of this site, my first job out of high school was aircraft mechanic apprentice for the Department of the Navy, and the F-14 was the first jet I worked on.
After that is PowerShell’s logo, which should be well-known to most folks reading this. PowerShell has been incredibly important to parts of my career, and has certainly made me something of a brand name. It’s also introduced me to some of the most wonderful and passionate people inside and outside of Microsoft – I just needed to acknowledge it, and them, in this tat.
Last but not least is Starfleet’s logo – the classic one, since that’s when I was a Trekkie. Through the end of high school and throughout my apprenticeship, I was a member of Starfleet: The International Star Trek Fan Club. Yeah, we were nerds. But we had heart: we’d wear our costumes to things like the local Children’s Hospital to cheer up the kids, we’d play Lazer Tag with the kids at the local Boy’s Club, and we helped run Star Trek conferences up and down the East coast. I learned a lot about management that way, and got to meet (and work with) some incredible folks – including Denise Crosby (ask me about her underwear sometime), Jimmy Doohan, George Takei, Walter Koenig, John DeLancy, Michael Dorn, and so many more. I made a lot of great friends. I also really learned to write – and write fast – as part of Starfleet. I wrote most of the early 1990s-era manuals for “Starfleet Marine Corps,” most of which mixed a fictional future-history with real technology education.
Anyway, thought you’d enjoy the brief stopover in geekville ;). I’ll post some pictures of the in-progress and finished product in my Twitter feed, @concentrateddon.
Unfortunately, fires sometimes happen. Right now I’m thinking about real fires: flames, danger, damage, injury, the whole deal. Fires aren’t something you think about very deeply while they’re happening: your goal is getting them out, while minimizing danger and injury. Actually, let’s take injury out of the analogy for a moment – pretend the building is empty of life and just burning on its own. Still bad, but perhaps easier to discuss clinically.
After the fire is out, the fire department almost always conducts an investigation. They may be looking for evidence of crime, of course, but they’re also gathering data. Insurance companies often investigate, too, looking to see if anything untoward or uncovered contributed to the fire – but again, also gathering data.
In many cases, the eventual outcome of all that data-gathering is substantive change to help minimize damage and prevent fires in the future. For example, back in the day, the designer of the cruise ship United States was really concerned about fires at sea. His generation had witnessed Titanic and numerous other at-sea disasters, and he was determined for his country’s new commercial flagship to not suffer the same fate. He designed the wall paneling in his new ship with an equally new miracle substance that simply wouldn’t burn. Nobody knew the dangers of asbestos at the time, of course, and the guy’s heart was in the right place. There’s an excellent book about the ship, by the way, if you’re interested, and its hulk is, I believe, still in Philadelphia.
Closer to dry land, you’ve got things like fire escapes, sprinkler systems, construction codes, and other factors that have all come about because of the gradual accumulation of data on fire damage. One client of mine, FM Global, is an insurance company. They spend tons of money helping their customers figure out better ways to not need insurance (thereby saving the insurance company money, of course, but also preventing substantial injury and damage, so it’s win-win). Again, it’s that gradual accumulation of data.
What everyone basically does is look at the cost of the damage, the potential cost of mitigating it, and decide if the one outweighs the other. Is it cheaper to include a sprinkler system in every new home (as is required in Henderson, NV, near where I live), even though many of them will never actually experience a fire? The accumulated data often suggests that yes, it’s cheaper to include the system in new construction when it adds only a few thousand dollars to the cost of the structure, and when it can easily prevent tens or hundreds of thousands of dollars in damages.
Back to the IT industry. Or really, any industry.
We all “fight fires” from time to time. Something breaks, and we scurry to fix it. What we don’t often do is have a fire inspector or insurance adjustor come and look at what happened, figure out what the cost was, and gradually accumulate that data until a solution – and its cost – becomes apparent. In other words, we tend to stick with fighting fires rather than preventing them. That’s often because we’re never bothering to figure out the cost of the fire.
Companies, in my experience, absolutely suck at costing things like productivity. Fixing the e-mail server when it’s down is important because the CEO isn’t getting his mail, and because he’s screaming about it, not because the company is losing money in productivity. With no cost to assign to the fire, it’s difficult to decide whether or not a solution would save money or not. Is it worth the money to implement a mail server cluster, so that the entire system is more available? Tough to say, right? Clusters are expensive, and if you don’t know the cost of the fire, it’s hard to tell if the cost of the sprinkler system is worth it.
I regard myself, at heart, as an engineer. Maybe not the kind that can call himself that in, say, Canada, but for all of my career I’ve designed and built solutions to problems. I’ve designed them to be resilient, reliable, and sound, much like you’d want someone to engineer a structure. Like many folks in my industry, I’m a “see the problem, fix the problem” kind of guy. But when I fix a problem, I want to fix the problem. The problem isn’t that “the email server is down,” the problem is that “the email server can go down.” So I’ve become fairly adept at costing failure.
Obviously, there’s no guarantee of accuracy, but you’re just looking to put some scope around the problem. Solutions cost money, and so you need to try and state the problem in money terms, so that there’s an apples-to-apples decision. How many people were affected by the fire? How much productivity did they lose? Was it a bunch of salespeople who need email to close deals? Then maybe they were 75% unproductive. How much do we pay them? How much of their salary was just wasted? It’s easy math. Was the outage short enough that no deals were lost, and we’re just talking lost salary? Okay, fine. With a ballpark figure, you can at least start having an intelligent, objective conversation about engineering a preventative measure.
I find that one reason I’ve always been valued in the organizations where I’ve worked is that I always seek a way to turn things into rational, objective conversations. It isn’t about the CEO being mad. That’s something the CFO has problem quantifying, although he or she can often empathize. It’s about the financial impact to the organization. Getting problems framed in an objective, impersonal, business-first way is how you get the conversation moving. You take it out of the squishy world of personality and into the more cut-and-dried world of numbers.
Of course, it means you need to know what you cost. A mail cluster isn’t just a collection of hardware and software; it’s also management overhead. How many man-hours does it take to maintain that thing annually? Are you automating most routine maintenance so that the answer is near-zero (if not, why not)? What hardware depreciation will occur?
Let’s take that last one as an example, because it’s an interesting thing that a lot of folks overlook.
All hardware, in most organizations, needs to be depreciated over five years. Even if companies take a first-year write off, they still have to track the asset’s value for five years. So let’s say you spend $50,000 on a new virtualization host. You’ve got to extract $10k in value from that each year for five years. If that host isn’t fully utilized, then you’re not realizing the full return on your investment. Let’s say you want to add a small mail server cluster node to that host, to provide yourself with some redundancy. You expect a mail cluster to help avert $500k in lost productivity per year, and that node will be half of the solution which does so. That means that node is worth $250k in value tot he organization – easily helping to offset the depreciation of that virtualization host, along with its annual maintenance and possibly its licensing costs.
It can seem a little irritating to have to break things down like that, but once you get into the habit, you’ll just know a lot of the basic numbers. An OS costs us x per year to maintain; a single VM represents x power and cooling, each IP address we configure costs us x to provision and maintain, etc. Knowing the cost of solutions makes it a lot easier to sell them against the problems.
Consider becoming, if your organization doesn’t already have one, the fire inspector and insurance adjustor for your team.