Tuesday, May 15, 2018

Leadership transition planning

Leadership transition planning is important everywhere. We usually think of leadership transition as a discussion item for the board room, but even open source software projects need to plan for future open source leaders. VM Brasseur's article How to develop the FOSS leaders of the future discusses several key elements for succession planning:
  1. Identify and analyse critical roles
  2. Refactor large roles
  3. Limit role tenure
  4. Knowledge transfer
  5. Document, document, document!

And during knowledge transfer, don't just assume the new person will be able to pick up everything on their own. For any successful transfer, there are several important elements, which VM identifies as:
  • Roles and their duties
  • Policies and procedures
  • Resources
  • Credentials
  • Project history
  • Transition plans

These are great advice for current open source leaders (or any other leader) planning their leadership transition. But what if you're on the other end? How do you step into a new leadership role? I'll share a favorite essay by Brian McDonald about Taking on a new role (PDF). When I moved into the campus CIO role at the University of Minnesota Morris, and when I later became CIO at Ramsey County, I printed out Brian's essay to remind myself of the important steps during my leadership transition:
  1. Share broad themes early
  2. Read the landscape
  3. Build relationships
  4. Create a SWOT profile
  5. Assess the talent to get the job done
  6. Get briefed on the finances
  7. Sketch out priorities for the first three to twelve months

Monday, February 26, 2018

Creating a development lifecycle

Today's popular application development model is DevOps, which is really about a relationship between development and IT operations. At its core, DevOps still relies on the same essential software development practices that have been developed over decades.

Some years ago, I managed an application development team. If you manage a similar team, you may know that developers aren't always fond of documentation. They'd rather get to the "fun" part: coding. But writing code means nothing if you don't know what you're supposed to do with it. Developers need a "road map" that informs them of how the application will respond to different input, what systems it will talk to, and other technical details.

I found a happy medium with my application development team. We agreed to a set of documentation that would grow with the project. At a high-level, we had five documentation "milestones":

  1. Statement
  2. Options (similar to a "Design" document)
  3. Diagram
  4. Roles and Responsibilities
  5. Lessons Learned

We defined each level of documentation as follows:

1. Statement

At project initiation, we created a high-level overview of the project. This was often created by the project team with the customer, and with input from the developers, to identify several items:

  • stakeholders
  • decision-makers
  • scope
  • problem being solved
  • introduction
  • background
  • who is affected?
  • timeframe
  • deliverables
  • roles and responsibilities (project)
  • technology
  • agile or waterfall?
  • customer involvement

2. Options

Before writing any code, the developers completed their own document to highlight items from the design document, and identify possible paths. This Options documented identified these things:

  • possible solutions, including pros and cons for each
  • technology
  • data sources
  • build vs re-use?
  • build vs buy?
  • where will this live?
  • architecture
  • policy surrounding the app
  • staffing
  • monitoring
  • backup and disaster recovery planning
  • other groups impacted

3. Diagram

While developers were creating the code, we asked them to capture a high-level diagram that showed how the application connected with other systems. For example, a web application might communicate with application logic on a separate middleware server, or with a back-end database. The goal was to make this diagram easy to understand, and identify these pieces:

  • hardware
  • software
  • inter-dependencies
  • organizations involved
  • encryption
  • transfer of data

4. Roles and Responsibilities

Before the application was ready for production, we required the project team to document the roles and responsibilities of the new system. This document answered who, what, where, when, and why, and answered these questions:

  • finalize definitions
  • handoffs
  • who does what jobs?
  • who does support?
  • who does database?
  • who does migrations?
  • where is the documentation?
  • who is the project team?
  • who are the maintenance contacts?
  • outstanding requests
  • known bugs, etc
  • how to request changes

5. Lessons Learned

After every release, whether successful or unsuccessful, we paused to identify what went well in the project, and what should be improved next time. The team would usually gather one or two weeks after the go-live so memories of the release were still fresh.

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 Opensource.com 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.)