Friday, April 28, 2017

Raising the bar on technology

I wanted to expand from my article this week about how technology should contribute to an organization. Technology systems can be a boon to organizations, when leveraged effectively.

But we also need to manage that technology effectively, too. Too often, I have observed IT organizations fail at systems management. "Information Technology" is more than setting up a few servers. You can actually put your organization at risk if you don't put in place certain safeguards to keep systems available to your end-users.

I have worked in technology for over twenty years. Much of that time was spent in infrastructure and operations, including leading the enterprise infrastructure and operations teams at the University of Minnesota: my teams supported over 1,100 servers at the university, running critical systems for over 65,000 students and delivering over 33,000 paychecks every two weeks.

In that role, I was frequently audited by our internal auditors, on average a little over once a year. Not because I was the subject of an audit; my department was audited about once every five years. Rather, because if the auditors examined another department, eventually they would review the servers that support them, and that meant me.

So through my own experience, I have developed a (growing) list of best practices to manage technology, at a level that satisfied our auditors. Here are a few highlights from that list:
  1. Redundancy in data center
  2. Architecture review
  3. Application management lifecycle
  4. Backup validation
  5. Disaster recovery planning
  6. Risk analysis
  7. Business value mapping
  8. Configuration management database
  9. Job automation
  10. Isolated file transfer
As I review this list, I think the data center (the first item in the list) is falling in importance. Most organizations are moving to Cloud, and I think that makes sense for many applications. Certainly we will always have some applications hosted locally, but it's not hard to predict that local data centers will be minimized, running only those systems that must connect to local devices (such as research, or managing IOT) or cannot be migrated to the Cloud for other reasons.

How does this compare to your environment? What would you add to this list?

Monday, April 24, 2017

Rethinking today's IT

Enterprisers Project ran an interesting article last year about Rethinking how IT drives business value in a digital age. A year later, the article still holds true on several levels.

In the article, author Sven Gerjets argues that as technology becomes more commoditized and instantly available, IT organizations need to rethink how they bring value. Gerjets writes:

"IT is now competing in a segmented marketplace where technology is far-reaching, easily accessible, and created at high volumes, which allow for economy of scale. … Competing in this consumerized landscape cannot just be about technology. Technology is too accessible; IT has to be about value creation and about learning."

Of course, IT must occasionally re-invent itself to remain viable. I've written about this before. In most original office settings, "IT" often referred to the folks running and supporting the mainframe environment. But as the cost of computing dropped, departments could purchase their own technology. In the 1980s, we saw an influx of "personal computers" in the business setting. Suddenly, "IT" had to compete with the PC, and IT adopted the PC as a business tool.

I got my first job in technology in the mid-1990s. Throughout my career, I have witnessed several upheavals in technology. The Web meant IT no longer had central control. Mobile devices like tablets and smartphones meant the "computer" was no longer a monitor sitting on your desk. The Cloud meant the network was the computer.

Every few years, IT needs to examine itself to see how we bring value and how we drive the business. As IT, are you "just" a support group, or are you engaged in how your organization operates? IT needs to empower organizations, and be a partner and a leader. Gerjets agrees, and concludes his article this way:

"We have to create an environment where our organizations are empowered to consciously learn, evolve, and raise the bar every day. This must be a learning organization that can intelligently collect information about its environment, is open to learning from others, learns from its failures and successes, experiments with new approaches, encourages problem solving, and most importantly retains and shares this information across the functions in IT. Organizational practices must be developed to systemically utilize these information stores in the IT planning processes to manage risk and to ensure that failure is not repeated while successful practices are repeated over and over again."

Monday, April 17, 2017

Open source software on your resume

Continuing my advice for students now getting ready for graduation, I wanted to share this great article from IT World, What to Include in Your Open Source Resume.

Do you participate in an open source software project? Maybe you fix bugs, write new features, test new releases, update documentation, maintain a website, manage their social media, or do any other other million things you can do to contribute to a project. If so, you should be sure to mention these in your resume. From the article:
Any job seeker wants to stand out, and if you're selling skills that you gained in an open source project you have additional opportunities to do so. At its most obvious, the experience makes you more attractive to open-source-friendly companies.
Listing your work in open source software can help you to stand out with a hiring manager. Among other things, it shows you can work independently while also working as part of a larger team. That's a rare ability that's sure to get you noticed, especially at a company that's friendly to open source software.

Zack Grossbart, software engineer consultant for Novell and author of The One Minute Commute, provides this advice in the article:
Open source or otherwise, you need to give potential employers enough background and details to they can be confident in the information you're giving them, says Grossbart. "If you're a C++ programmer from a big company that might look like, 'I was a C++ programmer for IBM for five years and worked on the following projects.' Your open source skills work the same way, 'I've been a committer to OpenOffice for five years and worked on the following features.'" The big difference: you probably need to tell someone what OpenOffice is and define "worked on."
Grossbart says to organize your contributions on your resume like this:
Describe the project.
Make it descriptive, but keep it short. If you can, describe the project in no more than one or two sentences.

Describe your contributions.
What did you do on the project? What did you work on? Provide more information than just "I worked on X project," but find a balance that doesn't list every commit. For example, you might say "Wrote programming libraries, including a library to support international languages."

Describe the team.
Hiring managers will want to know how the team was organized, and how you interacted with them. Was it entirely online, via email? Or did you work together in person. What was your role in the project?
Your work on open source software is valuable experience. Leverage it to your best effect in your resume.

Monday, April 10, 2017

For open source career-seekers

Following from my post last week, offering resume advice for new graduates, I wanted to share this brief highlight from about four must-read books for open source career seekers. This is especially relevant to me, because I spent this semester teaching an online class about usability testing in open source software (CSCI 4609 Processes, Programming, and Languages: Usability of Open Source Software).

The article isn't specifically about open source software, but about how to communicate your passion to work on open source software. So this is good general advice too. If you are a recent university graduate making the first step in your career, you may want to read these four books:

  1. What Color is Your Parachute (Richard N. Bolles)
  2. The Element (Ken Robinson, PhD and Lou Aronica)
  3. Finding Your Element (Ken Robinson, PhD and Lou Aronica)
  4. Networking for Nerds (Alaina G. Levine)

I've provided only the titles here. The article includes links and further discussion.

Friday, April 7, 2017

Class cues on resumes

It's April, and every year at this time I am reminded of my time in higher ed.

Graduation time is almost here for college and university students around the nation. When I worked in higher ed, I used to share advice around this time for our seniors who were about to graduate, suggesting tips and hints to improve resumes. With that in mind, I'd like to share this insight about resumes, from December in the Harvard Business Review.

Certainly the standard advice of Put your name at the top of the resume, Include your contact information (phone and email) right next to your name, and List your education and experience clearly still apply. But recent research suggests you need to be cautious about "How Subtle Class Cues Can Backfire on Your Resume."

The article describes "a field experiment with the country’s largest law firms" using a technique called the "resume audit method." You can find the details in the article, but the general concept involves inserting subtle class cues into resumes: last names, athletic awards, extracurricular activity, and personal interests. In each, and for both men and women "candidates," researchers crafted "higher class" and "lower-class" combinations in the resumes, then waited to see which resumes received callbacks.

The results indicate "biases related to social class and gender skew employment opportunities toward men from privileged backgrounds. Our research adds another twist to just how difficult it is for certain groups to get ahead, even when they achieve an advanced degree." The study was directed towards law firms, but the results may apply more generally.

Interesting information if you are a recent graduate applying for jobs. I also encourage hiring managers to consider how they ensure fair hiring. Are you responding to these subtle cues?

Monday, April 3, 2017

What not to say

I really enjoyed this article from last week, in Business Insider, about 11 sentences to avoid saying to your boss. Some of these are just painful to read. Here are a few highlights from the list, with my own commentary:

That can't be done

I recognize this as one of my personal trigger phrases. Yes, I know we are doing some tough work here, but that's part of the job. But I know you can do this. I wouldn't have asked you to do it if I didn't think you could do it.

We've always done it this way

Well, now we are going to do it a different way. Things change in technology; that's the nature of the industry. You know, we "always" used to run the mainframe to do critical work. And before that, we "always" used a paper-only process.

I'll quit

Thanks for letting me know. There's the door.

I'm quitting because I'm unhappy

Over my career, I've had a small handful of staff leave because they were unhappy. Some didn't like how their role was positioned; a few others didn't like the physical work environment. Almost anything can be changed around your work. If you are unhappy with how something is run in the office, please let me know. I will (and have) change things to make t hings better. Don't wait until you leave to tell me something isn't working right.

What should I do?

This is different than asking for coaching. If you need some direction, ask for advice. Don't ask me how to solve your problems, though. I hired you to tackle these issues, not keep asking me what to do.