Nine traits of the veteran Windows administrator

By Mark Underwood

March 9, 2011, 5:00 AM PST

Takeaway: A recent post about the traits of veteran Unix admins convinced Mark Underwood that there should be a Windows admin counterpart. See if you agree — and add some of your own.

There seemed to be many voices in the choir singing a tunesounded by an archivist of Unix admin traits. Here’s a humble return volley from the Windows corner.

No 1: Editor-free operations

We don’t need no stinking editor. Scripting is fine, and we admire those folks proficient with vi andemacs, but we’d really rather not fuss with it. If we have to script, we have Powershell, but most of us are too busy exercising our other eight traits to learn it.

No 2: Elevated-privilege awareness

The fallout from Vista’s evil public persona was that we became acutely aware of the pros and cons of both least-privilege and elevated-privilege operations. To paraphrase Churchill, never did so many suffer so much at the hands of a few. We’re aware of it in our work, and acutely aware of the effects of indifference to it among our user communities.

No 3: Workstations count more than servers

Server technologies get the glamor and garner the big bucks, but it’s managing service levels at the workstation that really counts. When the CFO’s Outlook client hangs, we have responsibility for the whole supply chain, from his/her laptop F9 key, through all the switches and routers, and to his Exchange mailbox. Whatever the underlying issue may have been, the Windows admin learns to accept calling it “the Outlook problem” without whimpering.

No 4: Google Search, not code

In comparison to other types of admins, we don’t risk inserting security breaches into our systems by writing specialized scripts, even if the affected task involves repetitive, manual tasks. Instead, we assume that someone somewhere has run into the same problem. We hop onto the nearest browser session and search for a fully-tested solution that has worked for someone else. Refer to Trait #1.

No 5: We prefer tested solutions

We try to stay off the bleeding edge. While we depend heavily on the world’s largest software firms to vet what we deploy, time-tested solutions usually win out over the latest and greatest. When a user has something really cool to try out, we turn to a new VM on a separate subnet or DMZ.

No 6: Postmortems are for consultants

We’re as geeky as the next geek, and marvel as much as the next geek over the elegance of a Stuxnet, but ultimately we’re clannish, organization types. When there’s a problem, we’re as curious as anyone else about the causes - even if research shows that we made a mistake. But more typically, we’re too busy dealing with the next rollout, the next crisis, or the next upgrade to dwell on it. We’re well aware that a sober, balanced, best-practices postmortem is best accomplished by a disinterested third party than an overworked admin.

No 7: We know what we don’t know

While we’ve dabbled with Red Hat and Ubuntu, and have worked hard to keep Linux machines happy in our server farm, we know there’s a time to dabble, and there’s a time to admit what we don’t know. We’re content to let other people maintain applications written completely in bash orcsh, especially those with no man page.

No 8: We assume the problem is with whomever is asking the question - but keep it to ourselves

We can strut our expertise in server and network products like anyone else, but we’re collaborators within a world of specialists. If we’re CCNA’s, we know better than to tell the Microsoft System Center Configuration Manager how she should be putting new VM’s into her system or manage desktop licenses across her network. Similarly, we expect to field questions from the occasional user who happens to know as much as we do about a specialization, and we see that as a good thing; here’s someone else to call upon when we need another pair of hands.

No 9: Network security is job two

Whether we are CISSP holders or not, we make it our business to know as much as possible about all facets of security measures the organization has in place. That includes everything from desktop disk encryption to apps and everything in between. We can’t use the excuse that “Windows is usually the target of attacks” as a reason not to be aware.

*Bonus: Know when to hold ‘em, know when to fold (reboot) ‘em

It’s true. Sometimes we have to reboot Windows. We wish we didn’t have to. We’d rather be at home with our spouses, watching a game, or having a beer with friends. We do worry that the latest patches might destabilize things or create new breaches. We console ourselves by reminding ourselves that while the server is off, no one can break into it.

[*Editor's update: Updated the duplication of numbers in above list.]

IT leaders: Why we do what we do

By Ilya Bogorad

January 4, 2011, 4:34 AM PST

Takeaway: For an IT leader, there are three key reasons for developing excellent understanding of the core business. Here are those reasons.

There is a reality TV show called Undercover Boss, where a senior executive of a large company takes a position at the bottom of the corporate pyramid. The executive discovers daily operations at the level of detail unknown in the executive suites. Epiphanies abound.

While the show is highly staged and predictable, and its entertainment value is questionable, few viewers are surprised that senior management knows so little about their core business. How do they run the company? Shouldn’t executive decisions be based on the knowledge of operations?

The distance between the executive suites and the front lines is often of galactic proportions. Because customers are found at the front lines (if you want to order a meatball sandwich or open a savings account, you don’t call head office), being light years away from the front line translates into being light years away from the customer.

The way I see it, the demand for management consulting services is not likely to go away anytime soon.

But never mind the executive management, the very same problem is common to many departments within your company. Did Marketing try that meatball sub before jumping into commissioning the jingle and booking the TV slots? Does Finance know how frustrating it is to work with us because our bills cannot be paid electronically?

And what about IT? This article is, after all, for IT leaders.

Of all departments, IT is perhaps the most susceptible to removing itself far away from the daily business operations. There are always islands of wonderful exceptions, but they are rarely where this knowledge is needed the most — among the IT management, where strategic and tactical decisions are made. Why do we do what we do? Does it matter?

I believe it does. For an IT leader, there are three key reasons for developing excellent understanding of the core business.

1. Improve quality of your decisions

The propensity of the human mind to generalize and simplify has been amply described in the business literature. It turns out that the best decision makers acknowledge that most decisions are complex and resist elimination of factors that appear unimportant.

If you do not know how your organization’s core business operates, who works on the front lines, who the customers are, and where they are coming from, to name just a handful of important attributes, you are missing whole layers of decision-making complexity.

These considerations are absolutely critical to all kinds of decisions, from project portfolio management (timing, scope, staffing, priority, etc.) to development and selection of methodologies.

2. Create better experiences for internal and external customers

When was the last time you tried to order a piece of equipment following the procedure you have had in place for years? Have you ever tried to call your help desk? What about using your project-intake process? How did it go?

If you don’t know your internal and external customers and the realities of their day-to-day decisions, you won’t be able to create products and services they need.

You may be able to create a product that is state-of-the-art and an aspiration to the whole industry. You may be able to create a promotion campaign that would be regarded by marketing professionals around the world as a masterpiece to be studied in business schools. However, if your customers don’t need or want it, you have just wasted a whole lot of precious resources.

3. Foster the sense of engagement in your staff

If you merely tell your staff to do something, you will get compliance, at best. It’s usually short-lived. If you manage to create a sense of engagement, an intrinsic connection to an objective or process, you will get a strong and durable commitment. It is the commitment that makes people want to invest themselves in a task or a project fully, to do their best, to excel.

Connect them with the business so that they see the impact of their work. Let them rediscover the meaning of what they do. You will see sparkle in your people’s eyes.

Just let me tell you Jason’s story.

On a recent project in a large health-care organization, we were looking to understand the dynamics of patient discharge so that it could be optimized. The better a hospital can manage discharges, the better utilization of limited resources it can realize, so this is very important.

Working with me was an MBA student, Jason. In his mid-twenties, Jason was well-educated, polite, and suitably cocky for his age. He was pursuing studies in health-care management but did not appear very sure of the career path after the university.

If you are familiar with process analysis and design, you know that it may be tempting to start drawing diagrams and analyze statistics. Analyzing a discharge process makes a beautiful study in swim lane diagrams and value maps in the hands of a process engineer, but I didn’t want Jason to lose perspective.

So, I sent him to the hospital floor to observe the discharge process firsthand.

He came back three hours later, pensive and humbled. Quietly, he told me that he had witnessed two families being advised that their loved ones were discharged because they had cancer. They would be treated elsewhere. In the eyes of patients and family members he saw the disbelief and the tears, the unanswered questions, and the sense of dire uncertainty.

What could have been an exercise in impersonal diagrams and timing has become filled with deep meaning for Jason. He worked on the project with dogged determination, guided by the sense of compassion and his internal commitment to delivering his best work.

I can also tell you that Jason is no longer unsure of what he is going to do once he finishes his studies.

Top 10 guidance tips for new CIOs and IT leaders

 By Isaac Sacolick

June 28, 2010, 12:09 PM PDT

Takeaway: Having almost reached the midpoint of his first 100 days in a new CIO position, Isaac Sacolick has developed some practical strategies that will benefit anyone who’s stepping into an IT leadership role.

It’s been awhile since my last post. What can I say; the first 100 days of being CIO at a new job is busy. There’s people to meet, the business to learn, and the technology to understand. Some things need immediate attention; others are things that can be dealt with later. It’s easy to be overwhelmed.

So, almost halfway into my 100 days, I can give new CIOs some advice. This goes beyond building the 100 day plan, which I think is critical to stay focused. This is my practical guidance for CIOs, but also for anyone taking a new senior technology leadership position.

This article is a reprint of an entry in Isaac Sacolick’s blog. It’s also available as a PDF download.

1: Ask lots of questions

The advantage of being the new guy is that people should expect it. I’ve been very fortunate in this new position and everyone’s been a good sport. Questions not only help you build up your understanding but also may help others see things from new perspectives. Occasionally, asking questions will expose an issue, but better now than later. And sometimes asking questions will help develop a culture of dialogue and collaboration.

2: Always be prioritizing

Your time now is at a huge premium. Set your schedule, but be prepared to change it as you recognize immediate vs. short-term needs.

3: Find ways to contribute early

Some call this quick wins, but even before that, relationship building is easier when it is two way.

4: Listen

Some of the “books” on management strongly suggest setting expectations with your staff early. I think before you set structure with your team, set time to first engage, listen, and learn.

5: Slowly zero in on the priorities

I stress here on the word slowly. It means go broad and learn more before setting new priorities.

6: Understand the business cycles and key dates

When are budgets done? When are the peak sales cycles? When are deployments scheduled? On my first week, I asked my directs to send me a list of key dates. All of this will help you prioritize your time and consider the timing of new initiatives.

7: People come before process and technology

CIOs tend to think in this trio, but in the first 100 days, focus needs to be on people and relationships first, process second, and technology a distant third.

8: Be prepared to run

Move fast. You have lots to learn, stuff to do, and plans to build.

9: Look for burning platforms

If I put 100 CIOs in a room, I doubt anyone would say that everything was running well when they took the job. In addition to priorities, you have to hunt down the issues — the ones everyone tells you about, but more important, the ones no one recognizes.

10: Leadership starts early

Don’t expect to sit in the back seat even though you’re the newbie. Your team, your colleagues, and your boss expect you to step up early. Will you be perceived as just the tech person, or as someone with a broader business understanding? Whether and how you participate is key to everyone’s early perceptions.

Isaac Sacolick is VP of Technology, CIO at McGraw-Hill Construction and has held CIO/CTO posts at BusinessWeek, TripConnect, and PowerOne Media. Isaac is an entrepreneur and specialist in media and publishing technologies, social networking, content management, XML search technologies, web analytics, data warehousing, digital advertising, enterprise 2.0, and agile management practices. Isaac writes a blog on Social, Agile and Transformationand is a frequent speaker on leading innovation in the enterprise and agile development practices.

10 IT positions ranked by prestige

By Alan Norton

March 14, 2011, 2:40 PM PDT

Takeaway: People often judge you by your job title — as unfair as that may be. Alan Norton ranks 10 IT job roles based on the degree of respect they command.

Humans have an innate desire to categorize everything from animals to social status. We do so because it is how our brains simplify and understand a complex world. People may categorize or stereotype you based solely on your job title — your prestige, or respect if you prefer, is determined by your position.

This class structure within IT is largely unspoken but real nonetheless. I will discuss it here and attempt to rank the following IT functions from most to least prestigious.

1: Systems analyst

The systems analyst is admired for his or her expertise in the multiple roles needed to build a successful system. They’re self-supervised and independent, and managers get out of their way and let them do their job. They are envied for their autonomy, high pay, and challenging work. They earn admiration for their high level of education, knowledge, and accomplishments. This unique combination puts the systems analyst at the top of the list.

2: Programmer

The programmer enters the room and a hush falls across the crowd. One person with awe and reverence showing on his face whispers in a respectful hush, “That’s the programmer who wrote the AI code!” Okay, programmers may not receive this amount of aggrandizement, but they are typically held in  special place of esteem.

To the average person, programmers do nothing short of magic. They make the Web come to life with a multitude of useful applications. They create new and strange virtual worlds. They enable computers to do everything from gaming to running essential functions of business. And they do so with mysterious and enigmatic languages known to only those select few who are the keepers of the code.

3: DBA

If you have done any database work at all and are fortunate enough to have a database administrator, you will appreciate the workload that the DBA removes from your plate. A smart developer learns early on that a good, experienced DBA is critical to the successful completion of the project. Part art and part science, DBAs’ skills can have a significant impact on the performance of the systems they help develop and support.

4: Project lead

Project leads who get their hands dirty and help with all phases of the project lifecycle are respected for their technical as well as their management skills. The role is not given to newcomers. Only those with years of experience make it to project lead. This alone is enough to earn the high esteem of the other project team members.

5: System admin

Access rights granted by sysadmins are just a hurdle in the completion their peers’ tasks. Sadly, the other good work they do goes unnoticed, primarily because even IT professionals have no clue what else they are responsible for. And all it takes is one bad experience trying to get system access for a user to lose any admiration for all system administrators.

6: IT manager

Unlike other professions, where manager would be at the top of the list, IT managers are hurt by the perception that they don’t do the “real work.” IT managers earn respect for their advancement up the career ladder, but this is offset by their perceived lack of technical skills. It may be unfair ,but managers lack IT cred. In addition, employees believe that their managers may have a general idea of their work but lack a detailed understanding of exactly what they do.

7: Network admin

Mention the words network admin to most, and these are the thoughts that are likely running through their head: “Isn’t he the reason I can’t see Facebook and Twitter? Sure, I get a blazing fast connection to the Internet, but what good is that if I can’t get to Youtube? He’s probably reading my email too!” No love there, and the network admin gets no love for the network being up, either — only grief when it goes down.

8: Reporting specialist

When you get right down to it, the reporting specialist is nothing more than a glorified cleric, pulling data from the system, putting numbers into charts, and spitting out reams of paper in the process. If you have to deliver charts with bad numbers to your manager, you may need to use this time-honored phrase: “Don’t shoot me. I’m Just the messenger!”

9: Technician

Never appreciated until a hardware or system emergency occurs, the lowly technician becomes associated with bad circumstances. You know there’s trouble if the tech shows up. He or she may be given the moniker “hero for the day,” but more often than not, users just want technicians to fix their system and be on their way. The uninformed may compare the technician’s skills to the auto mechanic or the Maytag repairman. Usually in crisis mode, the high stress, low pay, and difficult hours typical of the technician do not garner much prestige.

10: Help desk analyst

Help desk analysts are the Rodney Dangerfields of the IT world. The people answering the phone on the help desk get no respect from clients or other IT professionals. They are expected to solve as many problems as possible at tier one but are not paid the wages befitting that level of technical expertise. When the phone rings, there is almost always an unhappy customer on the line. Help desk analysts take unwarranted verbal abuse for circumstances beyond their control and are rarely recognized for their efforts. Their performance is typically measured by the number of calls they take and complete per hour — not exactly a formula for friendly verbal banter, lowstress, and thoughtful problem resolution. Respect? Even Rodney Dangerfield got more respect without the added stress.

The bottom line

Much of what I have written is totally unfair to the IT professional. Unfortunately, I believe it’s how many people perceive the IT roles I have listed — and perceptions can be difficult to overcome. While it is true that stereotypes and perceptions often predetermine prestige, it is equally true that prestige can be earned in the most mundane of jobs as well as lost by those in the most respected of jobs.

Unlike the social classes of Victorian England, where right of birth was the sole determinant of one’s class, the working classes of IT are open to all who are talented enough and industrious enough to achieve them. The reporting specialist, or any other IT role for that matter, can be a stepping stone to a better paying position with higher prestige. For example, I turned my reporting position into a developer’s role by automating the weekly charts. If you are looking to climb the prestige ladder, you can do the same. You only need to be clever enough and wise enough to recognize and seize the opportunities that present themselves.

I am reminded of the old joke where the body parts get together to decide which is most important and therefore should lead. One of the morals of the story is that all of the body parts are important. If you have a job that is low on the prestige ladder, you should walk proudly with your head held high. You know how hard you work. You know the unique skills required to do your job. You know how important you are to the overall success of the company. Never let anyone, including me, tell you otherwise.