Tuesday, October 10, 2017

From higher ed to local government

I wanted to share my article that recently ran in Government CIO Outlook Magazine, about moving an organization to cloud, and the balance of risks in cloud services:
Before I came to local government, I worked in higher education for seventeen years. Now as CIO at Ramsey County (Minn.) I apply the lessons I learned in academia to our work in government.

One thing you need to know about higher education is that budgets are very volatile. In public higher education, the overall budget is usually set based on tuition and total student enrollment, which is affected by the dips and rolls in student enrollment and retention. Some budgets are also based on State contributions. And one “off” year can impact budgets for more than just that year, or more than four years. Depending on the size of your campus, an unexpected dip in student numbers could have lasting budget impacts up to ten years later.

Working in higher education was certainly rewarding, but it was a constant challenge to meet a modern campus’s needs in the face of ever-shrinking budgets. In the seventeen years I worked in higher education, it was rare to see an increase in my annual budget. Most of the time, we had to “do more with less.”

As a result, we became very entrepreneurial in delivering solutions, and I learned to leverage new tools that allowed us to deliver value to the campus within limited means.

For example, for many years until 2010, I managed several departments that supported enterprise infrastructure and operations at a large university. We had a respectable budget, but I couldn’t rely on the same numbers every year. To support enterprise applications within a limited overall budget, we considered new options, including open source software systems. We found Linux delivered the same power and flexibility as the “big iron” systems, at a fraction of the price. We were the first to implement “Linux in the enterprise” at the university, and within a few years we began displacing our more expensive Solaris and AIX Unix servers with Linux, reducing our technology spend by a considerable margin. By the time I left the university in 2010, about two-thirds of our enterprise systems ran on low-cost Linux servers.

In 2010, I became the IT Director and campus CIO at a small liberal arts campus. Due to our relative small size of about 2,000 students, I inherited a small budget. Again, we looked to new frontiers to support our campus within limited means. We quickly moved many campus applications to the Cloud, reducing the technology footprint in our local data center, while maximizing our Return on Investment. And while my campus may not have been the first higher education institution to explore Cloud solutions, we were certainly among the first.

Almost immediately, we migrated our email and calendaring systems to Google Apps for Education, which included Gmail and the other Google Apps. Soon afterwards, we moved our home-grown academic alert application to a Cloud system. Other systems, including a database of campus committee meeting minutes, and a hand-coded website with over 40,000 objects, also moved to the Cloud.

Leveraging the Cloud allowed us to lower our costs while expanding our campus services. In off-loading applications to the Cloud, we could retire old servers and storage, reducing our maintenance costs. Support staff were freed to work on more valuable tasks. Our developers shifted from writing applications to providing integration services.

My vision in higher education technology was simple: if the service had become a commodity, we should outsource it to the Cloud. I wanted my staff to focus on the services where we truly added value. This alignment to “Cloud v Local” helped us to lower our Total Cost of Ownership, while remaining flexible to campus needs. And most importantly, we could operate within our means and “do more with less.”

In my last year at the campus, we began to explore new ways to provide technology in classrooms and computer labs, leveraging new low-power computing devices like the Raspberry Pi, Google Chromebox, and Intel ComputeStick. Over the next four years, I expected to reduce our general-purpose computing costs by ten percent or more.

In December 2015, I moved from higher education to local government. As Chief Information Officer, I direct and manage all aspects of Information Services for Ramsey County, Minnesota – an organization of more than 4,000 full and part-time employees working at more than 20 separate locations. I work through governance to lead the vision, strategy, and governance for information technology in the county, ensuring alignment with the county’s vision, mission, and goals and industry best practices.

Former colleagues have asked me how local government differs from higher education. I tell them the two are very alike: local government has the same governance, committees, organizational structure, everything. It’s just labelled differently.

But one thing is different in local government: we don’t embrace change like we did in higher education.

In local government, our funding model is more reliable. Where higher education budgets were dependent on student retention and tuition, county budgets are largely a factor of the tax levy, so are more stable.

With more predictable budgets, the county hasn’t faced the same pressures to try new things. We can continue to rely on the same services and solutions next year, because the budgets rarely shift. We don’t have to look outside the way we do things. We aren’t pressured to “do more with less.” Thus, today’s government technology looks about the same as it did ten or fifteen years ago. It’s the same across other local government technology organizations. The back office for local government often runs on Microsoft Windows. Most government applications run locally, and many of them are developed in-house. That’s all we’ve known, and we haven’t had a reason to change.

I intend to change that, at least in my organization. In the year and a half that I’ve been here, I’ve worked with our technology teams and with governance to re-examine our purchasing decisions. Where we once feared the Cloud, we have begun to take our first steps to a Cloud-first future. In the last year, and where it makes sense, we’ve replaced several on-premises applications with Cloud systems. I expect over time, we will use more Cloud.

Today, we use Microsoft Windows on the desktop, but maybe that will change over time, too. As we continue to use more Cloud, delivered via a web browser, the desktop will become less important. There could be a time, perhaps in a few years, where the desktop won’t matter so much. That will be an interesting change for an organization that has used the same core platform since 1995.

And it’s my role as chief information officer to help my county realize the new modes in technology, and to help shift us toward the future. This is a cultural change, so I don’t expect to see immediate results, but I’m confident that we’ve already started to move towards a mindset where we are open to new experiences, to trying grand new experiments. I think we’re on a path to “do more with less.”

(Jim Hall. "CIO Viewpoint: The Risk Game in Cloud-Based Services." Government CIO Outlook Magazine. September, 2017.)

Thursday, October 5, 2017

Leadership lessons from open source software

Earlier this year, I wrote an article for CIO Review Magazine, discussing leadership lessons from open source software. I wanted to share the essay with you here:
I’ve been involved in open source software since I was a university student, both as a user and a contributor. Today, I’m a chief information officer in local government. While my day job is unrelated to my personal interest in open source software, I find leverage in many of the lessons I learned throughout my history in open source software projects.

Let me first share my background. I’m of an age that I used MS-DOS when I was growing up. MS-DOS was pretty much the workhorse operating system of the 1980s and early 1990s. If you had a desktop computer in the office, the odds were good that the computer ran on MS-DOS.

As an undergraduate physics student in the early 1990s, I used MS-DOS for everything. I wrote papers in a DOS word processor, I analyzed physics lab data using a DOS spreadsheet, and wiled away my free time by playing DOS games. I considered myself a DOS power user. So I was understandably upset when, in 1994, I read in technology magazines that Microsoft planned to do away with MS-DOS with the next release of Windows.

And so I decided to create the FreeDOS Project, an open source software project to create a free version of DOS. FreeDOS caught the interest of many developers, and in over the next few weeks, dozens of developers from around the globe joined our growing open source software project.

Since 1994, I have served as the Coordinator of the FreeDOS Project. In this capacity, I helped bring developers together to collaborate on programs, created “vision” statements and other documentation to get us all pointed in the same direction, and I oversaw each release of the FreeDOS Operating System, from Alpha 1 in 1994 to version 1.2 in December 2016.

FreeDOS is only one part of my open source software experience. I have served as founder and coordinator of several open source projects, and contributed as a developer to dozens more: the GNOME desktop, a music player, a game, a compiler, an editor, and other programs. And in working in open source software, I have learned many lessons about leadership that I apply every day in my professional career. I’d like to share three key lessons from open source software that I’ve carried into my career as chief information officer:

Feedback is a gift
Every software project, whether open source software or traditional “closed source” software, will have bugs. There is no program so perfect that it is without bugs. In open source software, we rely on bug reports. That’s our feedback to what’s working and what’s not working.

But your open source software won’t get far if your default response to bugs is to make excuses. If a user discovers a problem in your software, you need to accept that feedback, fix the bug, and move on. If you instead respond with excuses (“But I did that because …” or “But that’s something you should avoid anyway”) then your open source software project is doomed to fail.

Similarly, in leadership, you need to accept feedback and comments, from all quarters. Feedback is a gift, and we should seek out feedback so we can improve ourselves. At the end of any large meeting, I like to pause and ask for feedback. A simple exercise to identify what worked and what we should change next time helps to keep things on track.

When soliciting feedback, your audience needs to know that you will listen to what’s said. Resist the temptation to respond with excuses (“Well, we did that because …”) but instead accept the gift, and say “Thank you.”

We all need to hear feedback from others, even if that feedback is difficult to hear. Managers who receive feedback from their staff become more effective managers, including coping with their emotions, empathizing with individuals and resolving conflict. But managers who do not receive feedback from staff are less likely to change their behavior.
Everyone brings different viewpoints
And those viewpoints make for a stronger open source software project. Eric Raymond coined “Linus’s Law” about open source software development, claiming “Given enough eyeballs, all bugs are shallow.” (Raymond, The Cathedral and the Bazaar, 1999.) More properly, the law states “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.”

When you have many developers involved in an open source software project, the solution to a problem will be obvious to someone. But one developer working alone may find they are stumped to find a resolution.

The same holds true outside open source software, in any organization. We don’t have all the answers. As a friend and colleague often advise, “the answer is in the room.” I find it helps to prompt a conversation with “How might we accomplish this?” The phrase is open-ended and encourages participants to find a solution.
You don’t have to do it all yourself
In open source software development, it can be tempting to do everything on your own. Many people get into open source software for the sense of accomplishment, and there’s nothing like creating a software package on your own to feel like you’ve really achieved something.

But you won’t get far in open source software with a “do it all yourself” attitude. In any sufficiently large or advanced project, you need to work together with users and developers.

Years ago, a mentor helped me realize that an effective leader delegates. I used to struggle with delegation; I always thought I could do it better myself. I feared that someone else might do the task incorrectly, or at least not to my preference. But we can’t do everything; we need to pass on assignments to those in our teams, and trust that they will do the right thing.
Looking for leadership lessons through the lens of unexpected sources can be interesting and insightful. We need to find inspiration from everything we experience. For myself, I like to reflect on what I have done, to find ways to improve myself.

As chief information officer, I leverage many of the lessons I learned from maintaining or contributing to open source software. While I find insights from other areas, experience drives learning, and my twenty years of personal experience in open source software has taught me much about accepting feedback, listening to others, and sharing the burden. This applies directly to my professional career.

(Jim Hall. "Leadership lessons from open source software." CIO Review Magazine. August, 2017.)

Tuesday, September 5, 2017

Ask for feedback

Jim Bruce shared a great insight on his blog about how to get feedback. Jim writes: Recent work by the NeuroLeadership Institute suggests that feedback is better received in response to you asking for feedback than when someone asks, “May I give you feedback?” and you respond “Yes.”

It's a great article and I encourage you to read it. Jim discusses several dimensions around how we receive feedback the way we do, and provides encouragement to actively ask for feedback:
Asking for feedback, in reality, is an opportunity for you to take control of a segment of your development and seek information that will be specifically helpful for your growth. If you run a meeting, be sure to do a plus/delta about what worked in the meeting and what didn’t. And, you can go beyond that with directed questions, seeking feedback about specific segments of the meeting. If you give a presentation, get feedback from several in the audience. Don’t ask the “softball” questions that lead to “you were great” answers. Ask the harder questions pointing to sections of your presentation, or how you responded to questions, where you felt you were a little “rough.” It’s all about learning what you need to do so that you will grow and do better work in the future. And, do say, “Thank you for your feedback.” and don’t make excuses for your shortcomings, etc. It is what it is.

While I don't always ask for feedback, when I do, it's always intentional. I find that I best receive feedback if I prepare myself mentally. When I want to get feedback, I tee it up with something like "This may be the first time you've seen this, but I'd like to get your first reaction" or "What did you think?" Or "Let's do a quick plus/delta exercise from today's meeting." However I tee it up, I always follow with "Feedback is a gift." Because to me, feedback truly is a gift.

But that phrase also helps me to get into a certain mindset to really listen to the feedback, to process it. By saying "Feedback is a gift" out loud, and hearing myself say it, I'm giving myself permission to actively listen to comments.

The feedback is what it is. If it's positive, I capture that. If it's a delta, I capture that too. I may process things afterwards, so the comments can "marinate" in my brain and get me thinking differently. But as each person gives their feedback, I try to respond with "Thank you, I'll take that." Very rarely do I catch myself saying "But" in response to feedback.

Good feedback only matters if you listen to what's said. Don't make excuses. Take the comments, reflect on them, and use them to improve.

Monday, May 29, 2017

Disaster Recovery vs Business Continuity

Disaster Recovery is not the same thing as Business Continuity. For an example, you need look no further than the recent British Airways system failure. Lasting several days, the outage affected more than 75,000 passengers across 170 airports in 70 countries. During the outage, British Airways could not process passengers, meaning outbound flights could not take off, and planes were stuck at gates.

The problem began with a power surge that "only lasted a few minutes", but the back-up system had not worked properly.

There's a lot of finger-pointing at British Airways, but I prefer to use this as an example of how Disaster Recovery is not the same thing as Business Continuity.
A disaster is when things fail.

Disaster Recovery is the IT folks bringing servers back up and getting computer systems back online.

Business Continuity is how the business keeps operating in the face of the IT system failure.
In the case of British Airways, the IT folks were busy restoring power to the mainframe, bringing up the backup system, and synchronizing data. That's Disaster Recovery.

Meanwhile, in the airports, on-site staff used whiteboards to communicate flight status, and used runners and other communication methods to get information between gates. That's Business Continuity.

Take this opportunity to review processes and procedures in your own organization. What does your Disaster Recovery plan look like? Do you have one? Does everyone in the IT organization know how to bring systems back online in the face of failure?

At the same time, what does your Business Continuity plan look like? This needs to come from your business units, to plan how they will keep operating if the technology becomes unavailable. The Business Continuity plan cannot be to yell at the CIO until systems come back online. Every business unit needs to create and manage their own plan about how they will continue to do business in the sudden absence of technology.

Monday, May 15, 2017

Common security issues

I have been working in IT for over twenty years. I got my start as a Unix systems administrator at a small company, then moved into a "working manager" role at another small company, before moving into higher education where I eventually led the Enterprise Operations and Infrastructure teams for a Big Ten university. After that, I transitioned to a campus leadership role, as campus CIO at a coordinate campus. Now I am the chief information officer for county government.

In my time working in technology, I have watched the rise of online security. When systems are connected to the Internet, they are at risk to cyber attack. In 2017, if cyber security is not a key focus area for your organization, you are falling behind.

As if to demonstrate, the UK's National Health Service (NHS) was recently stung by ransomware, a common form of attack. This was one of several WannaCry attacks worldwide. And if  you're still running Windows XP, it's only going to get worse.

What are the security issues you should be most concerned about? While I don't claim to be a security expert, I can speak from some experience here. This is part of my list of the top security improvement opportunities for most organizations:
  1. Patching, and retiring out of date systems
  2. Intrusion detection
  3. Automated system monitoring
  4. Private IP space and bastion hosts
  5. Distributed architecture
  6. Separation of privilege
  7. Access controls review
  8. Single sign-on, with two-factor authentication
  9. Firewall and VLANs
  10. Data at rest encryption
What would you add to the list?

Monday, May 8, 2017

High academic vs Low academic

I loved this article from The Conversation, about how Academics can change the world, if they stop talking only to their peers.

Having spent seventeen years in higher ed, much of the article resonated with me. From the article:
This suggests that a lot of great thinking and many potentially world altering ideas are not getting into the public domain. Why, then, are academics not doing more to share their work with the broader public? The answer appears to be threefold: a narrow idea of what academics should or shouldn’t do; a lack of incentives from universities or governments; and a lack of training in the art of explaining complex concepts to a lay audience.
The article reminds us that many academics don't believe it's their job to communicate with the lay public. There's really no motivation to do so. If you're chasing tenure, writing in trade magazines or newspapers may not "count" towards your publication credit, anyway. And once you have tenure, writing for non-peer-reviewed venues may be considered "cheap."

I observed that attitude several times when I worked in academia. I remember our campus held an annual celebration of scholarly faculty achievements. Faculty were invited to submit samples of their work that had been published in the previous year. I also remember commiserating with friends in the faculty who failed to get recognized because they wrote in non-academic journals and magazines. They wrote for the common reader, not other academics.

The article also highlights that even when academics feel motivated to write for a broader audience, it may be difficult for them to get published. As the article points out, "Writing an article for an academic journal is a very different process to penning one for those outside the academy." When you've been trained to write "academic" speech for your whole career, it can be difficult to construct prose that is more approachable.

I have a similar view. When I was in my Master's program, I referred to three different styles of writing: "High academic," "Medium academic," and "Low academic."

High academic is typical for many peer-reviewed journals. This writing is often very dense and uses large words that demonstrate the author's command of the field.

Medium academic is more typical of undergraduate writing. It is less formal than high academic, yet more formal than what you find in the popular press.

Low academic tends to include most professional and trade publications. Low academic authors may sprinkle technical terms here and there, but generally write in a way that's approachable to their audience. They use contractions, although sparingly. Certain other conventions continue, however. Numbers are written out; "fifty" instead of "50," and "two-thirds" instead of "2/3."

In my Master's program, I learned to adjust my writing style according to my instructors' preferences. One professor might have a very formal attitude towards academic writing, so I would use High academic. Another professor might approach the subject more loosely, so I would write in Medium academic. When I translated some of my papers into articles for magazines or trade journals, I wrote in Low academic.

Academics need to adopt a similar approach. It's okay to write in High academic when you are writing for your peers, in academic journals. But the academy needs to be visible to the public, to share their findings in a way that non-academics can understand. That means adopting a Low academic style.

The article concludes with a similar message, but also adds that universities need to change their attitude about what should "count" as "publication," saying:
Doing this sort of work ought to count towards promotions and should yield rewards for both universities and individual academics. Quality academic research and innovation are crucial. It is equally important, though, to get ideas out into the world beyond academia. It could make a real difference in people’s lives.
And I agree.

Thursday, May 4, 2017

My start with Linux

When I was an undergraduate physics student, I discovered this little thing called Linux. It was a great Unix operating system that I could run on my PC. And I've been a Linux fan ever since.

I wrote a full story for OpenSource.com, about How I got started with Linux. Please read it!