Monday, February 12, 2018

Coaching Buttons - the book!

Since 2008, I've been writing about issues facing IT leaders. In 2013, I moved to the "Coaching Buttons" blog.

The name "Coaching Buttons" comes from a topic I sometimes refer to in this blog. Coaching buttons are opportunities to have a brief coaching conversation with someone. Never waste an opportunity for coaching, however brief. For example, a manager might find him/herself early for a meeting, only one staff member is there, giving the manager a short time for a "coaching button." The "coaching button" might only cover one question without an opportunity for follow-up questions to delve deeper, but if you can find frequent opportunities for several "buttons," I find it can be helpful.

Each of my essays about IT leadership is a separate "coaching button."

I've finally collected many of my essays into a book. This collection of essays are coaching buttons on leadership and vision in information technology: how to be a leader, how to lead through change, and how to do strategic planning. These are the essentials of good leadership.

You can purchase the book Coaching Buttons at publishing partner Lulu.
image: Coaching Buttons

Monday, December 25, 2017

Top ten from 2017 (part 2)

Following up from part 1 of my top-ten list, here's the rest of my favorite articles from this year. Enjoy!

(6) Above/below the line
Throughout my career, I've led many IT consolidation projects. The first thing many people will ask is "how will this affect me?" I like to use a simple model to describe how consolidation will actually help others to focus on the things that matter most to them, on the tasks that will provide the greatest value. Let the IT department take on the heavy lifting of managing the network, servers, storage, and operating systems - so business units can focus on the applications that let them do their job.
(7) How to write an email
When communicating with others, especially in a time-asynchronous mode like email, it's important that you strike that balance between "the right amount of information" and "not too long." In writing my own emails, I follow the general advice of: (1) Write email, (2) Delete most of it, (3) Send. In this essay, I provide some guidance and examples to send just the right amount of information without overloading your reader. No one wants to read a novel of an email.
(8) On open government
I've been part of local government since December 2015, and I love it. A key goal for open government is transparency, and at my county we have implemented an open data portal for our residents and others to access raw data about the county. A similar item at discusses open government. I wrote a brief item in March 2017 about open government.
(9) What not to say
I found an article that shared eleven sentences never to say to your boss. Some of these are truly painful to read. I highlighted five from that list, with my own commentary. "That can't be done" or "We've always done it this way" are guaranteed to annoy me instantly. What other phrases irritate you the most?
(10) Raising the bar on technology
I've worked in technology for over twenty years, and over most of my career, I was included in an audit about once a year (on average). As a result, I've developed my own list of best practices to manage technology systems effectively. This is a brief overview of that top-ten list.

Monday, December 18, 2017

Top ten from 2017 (part 1)

I've slowed down in writing on the Coaching Buttons blog this year, as I write more articles for magazines and journals. But I have posted several items here that stand out to me. As 2017 winds down, I'd like to share my top ten favorite blog articles of this year. In no particular order:

(1) High Academic vs Low Academic
How effectively do you communicate? The field of international communication espouses a spectrum of "high context" to "low context." Borrowing from that idea, I view writing styles on a spectrum from "high academic" to "low academic." Change your writing style to suit the audience and the venue.
(2) Disaster Recovery vs Business Continuity
Disaster Recovery is not the same as Business Continuity. The business needs to prepare for business continuity, while IT organizations need to be ready for disaster recovery. How prepared is your IT organization to respond to failures? And remember, "disaster" doesn't always mean "smoking hole in the ground." A disaster can be large or small.
(3) Leadership lessons from open source software
I've been involved in open source software since 1993, and a contributor to open source software projects since 1994. I've learned a lot about leadership from open source software. In this essay, I share some key lessons about leadership from my background in open source software development.
(4) From higher ed to local government
In higher education, our budgets were very volatile, being very dependant on student enrollment quotas and tuition. As a result, we were often forced to "do more with less." And my IT teams rose to the challenge, exploring new options and new technology to solve problems. But in government, budgets tend to be more stable. Next year's budget will probably be similar to this year's budget. So folks become less willing to try new things. I'm hoping to change that.
(5) On resource planning
How do plan ahead for the work you need to do? I find that using a simple spreadsheet to track upcoming work is a great way to balance tasks against time. And the spreadsheet provides transparency to our customers, so our peers can see what we are doing. Here's a simple explanation to create your own time tracking spreadsheet.
I'll share the rest of the top-ten list next week.

Tuesday, November 7, 2017

Questions to ask about disruptive technology

Corporations are designed to work with sustaining technologies, but this isn't always the case in today's business world.  Sooner or later, along comes a ground-breaking change, and a disruptive technology shakes everything up.

How do innovative CIOs recognize when there is an opportunity to take advantage of the change to have future success? They must collect data and retrace each step in order to focus on the value risk and impact this new technology will have. It is critical for technology leaders to understand which technologies will matter and prepare accordingly. To disrupt or be disruptive, that is the question!

What are the questions to ask about disruptive technology? Here are a few thought experiments or questions to ask yourself in preparing for disruptive technology:

How does your organization think about and prepare for what’s coming next? For example: at a previous organization, I created an "Advanced Labs" concept, where interested and motivated staff coordinated with their managers to participate on 20% time to explore emerging tech. It helped us to better understand some new concepts and get ahead of it.

Have you introduced a disruptive technology? Many of us in IT have had a good idea before its time. What have you introduced, or tried to introduce? How did that shape the landscape of IT at your organization? Did you experience resistance or quick adoption?

How do you decide if an emerging technology has failed to become “disruptive”? What did or didn’t work, and why? What decision points do you use to determine if a new tech hasn’t really caught on, or hasn’t been very disruptive? What determines “success” of an innovation? Is it ROI or connection to business, or some other reason?

What are some general strategies you prefer to remain flexible for new technologies? For example, we can assume any new tech will probably require wireless networks. What other strategies or assumptions do you carry?

What about security issues? In the interests of “getting things done,” new technology may not always have security as a priority. IOT is an example. How do you balance security or legal or compliance issues with emerging technology? How do you manage security for emerging technology?

What about team capacity? Is your organization capable to take on the new technology? Who’s going to run it or support it? How do you staff resources for this?

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.