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!

Monday, May 1, 2017

Every meeting

I'm taking a break this week (I'm grading final exams for the online class I'm teaching this semester) so instead of a longer post, I wanted to share this brief video from FastCompany.

» Every meeting you've ever been to (in two minutes)

How many meetings have you been to that are like this?

Sure, the video is funny, but that's not the reason I shared it. I'm hoping the video may knock you out of complacency, and get to you recognize any of these bad behaviors in yourself (if you have any). So if you're exhibiting any of the traits from this video, if you listen to yourself in your next meeting and hear yourself saying some of these trite examples, you need to find new ways to express yourself.
image: FastCompany

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.

Saturday, April 15, 2017

Jumping off points for audiobooks

I used to have a regular three-hour commute. During that time, I listened to a lot of audiobooks. When I tell people about my long drives, I often joke that I could recommend several good audiobooks.

And I have. Last year, I shared a short list (see part 1 and part 2) of audiobook recommendations. Most of these are from an audio production company in the UK called Big Finish. They put out a lot of great full-cast audio productions, which is kind of like listening to a great TV program. Among other things, Big Finish is especially well known for their excellent Doctor Who full-cast audio stories. Big Finish has the BBC license to make audio stories, featuring the original cast.

A friend is about to take a long trip, and asked me for audiobook recommendations. And as usual, I started with a few Big Finish titles. I thought I'd share the similar list here.

If you are a fan of the classic Doctor Who, I hope you will enjoy this list. I've selected stories based on a a few criteria: they are all stories I love (and often re-listen to), they are all quite inexpensive, and they are all good "jumping off" points. These are older titles that have "earned out" at Big Finish, so they are available at a big discount. Here you go:

Doctor Who

The well-known, long-running BBC science fiction program. I've arranged these stories according to Doctor.

5th Doctor

Peter Davison as the 5th Doctor, with companions old and new.

6th Doctor

Colin Baker as the 6th Doctor, with new companions.

7th Doctor

Sylvester McCoy as the 7th Doctor, in a free one-off story.

8th Doctor

Paul McGann as the 8th Doctor. A few stories featuring new companion Charlotte (Charley) Pollard.

Spin-off series

Several spin-off series. Except for Unbound, these don't require much (if any) familiarity with the TV show.


A few stories from their "What-if" series, featuring new actors as the Doctor. Non-canonical, but very good.


Earth is at war with their own android creations in Orion, and leverage captured Cyberman technology in a bid for victory. Series 2 is less good, so I'm not recommending it. But it ends well at series 1.
  • Cyberman 1 (eps 1, 2, 3, 4 : $3 each, or $12 for a bundle of all four)

Dalek Empire

The Daleks conquer the human race, and our struggle for freedom. Series 1-2 are good, but I think series 3-4 are quite dull; series 3-4 take place well after series 2 anyway, so 2 is a good stopping point.


More closely related to X-Files, about a military unit that investigates unexplained encounters.
  • The Coup (prequel, free)
  • UNIT (eps 1, 2, 3, 4 : $5 each, or $15 for a bundle of all four)

I, Davros

About the creator of the Daleks, this tells the story of Davros as a young man during the Thousand Year War.
  • I, Davros (eps 1, 2, 3, 4 : $5 each, or $15 for a bundle of all four)

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 OpenSource.com 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.

Wednesday, March 29, 2017

Your privacy at a price

By now, you've probably heard of J.Res.34, which will permit your Internet Service Provider at home to sell your browsing data to others. I admit that this wasn't on my tech radar until it happened. That's because this bill is extremely stupid and I assumed it would never pass.

Welcome to the new world, I guess.

The Electronic Frontier Foundation has a list of five ways your cybersecurity will change once this is signed into law:
  1. Your ISP will now snoop on you
  2. Your ISP will probably break encryption
  3. Your ISP will probably insert ads on web pages
  4. Your ISP will create supercookies to track you
  5. You are at risk for spyware
I agree with the items in the article. I think the loss of privacy will be the first thing the general public will recognize in this. The other points are also important, but they aren't as visible as privacy. Now your ISP can sell your browsing habits, including your visits to Google, GMail, Amazon, Target, Apple, Hulu, Netflix, YouTube, CNN, BBC News, Facebook, Twitter, porn, etc.

I suspect the first thing ISPs will do is monetize your online activity at a broad level. They can very easily identify when your home is passing the most traffic. Do you go online in the morning, reading the news over breakfast? Do you do much online activity in the evening? Advertisers can use this information in various ways to build a better picture of you.

After that, I think ISPs will monetize DNS lookups. That gives a broad look at what you are doing. And it's relatively straightforward to create a log of DNS lookups. What websites do you visit most often? When do you visit them? By itself, that's very bad for privacy. But people can use other DNS providers (like Google Public DNS) so this will not be the final step.

From there, I think ISPs will do deep packet inspection. By inspecting traffic at greater detail, the ISP can see what pages you are looking at. That's where they will unravel your "https" request and create what's called a "Man in the Middle" (MITM). There are products that do this today, for corporate networks. And the EFF article correctly points out that this creates a security vulnerability. So now you don't have to worry if your browser is up to date on security, you have to worry if your ISP's MITM is up to date on security.

I fear the day that ISPs decide to insert ads into your browsing experience. This will not go over well. Imagine an H&R Block ad appearing on the Apple.com website around tax time, because your ISP inserted an ad. That happened. Other ISPs have tried inserting ads on web pages before, and received such negative feedback they stopped doing it. But I think that day is coming back.

More likely over the long term is we'll see ISPs offering another tier of service. "Don't want us to sell your data? Upgrade to our Privacy-plus plan for an extra $20/month." But by then, will you trust your ISP anymore?

Monday, March 27, 2017

Technology trends for 2017

Technology is always changing. You don't have to go back very far to see how quickly technology evolves. Ask yourself how things will be different a few years from now. IT organizations must adapt to constant change, or they will die.

Along those lines, an article at The Enterprisers Project shares these eight big trends that will impact IT in 2017. From the article:
  1. US government deregulation
  2. Rise in state-sponsored cyberattacks
  3. IoT security as first priority
  4. Geo-fencing for mobile app push notifications
  5. Digital customer experience as important as the product
  6. App modernization for consistency
  7. AI will be everywhere
  8. Displacements due to digital transformation and demonetization displacements
How do these stack up in your organization? Look ahead to the coming year and ask yourself what changes you envision for your future and your organization. Don't be the next CIO who might have brought change. Be the CIO who embraces change.

Monday, March 20, 2017

On open government

An item at Opensource.com discusses the topic of "Open Government." This is timely for me, because where I work (local government) we have been building a new Open and Accessible Data Portal. Open data and open government is the new norm. Government is "of the people, by the people, for the people" (Lincoln, Gettysburg Address, 1863) and open data makes information about your government available to you, the taxpayer.

The Opensource.com article describes open government as "one with high levels of transparency and mechanisms for public scrutiny and oversight in place, with an emphasis on government accountability." Another way to describe open government is providing information in an open and accessible way, without filters.

The key goal for open government is transparency. Anyone should be able to view information about the government.

Open data laws require that public and government organizations provide information upon request, such as a US Freedom of Information Act (FOIA) request. There are a few exceptions, such as information related to security, but generally any information is accessible by making a FOIA request.

Open government takes this a step further. Why wait for the request before we make it available? Let's share the information proactively. If we can provide the raw data, governments should provide that.

And that's exactly what we are doing at my county. I'm proud to do this work.

Functional and Unit organizations

A colleague pointed me to a great article about Functional vs Unit Organizations. It's a long article, so it's difficult to summarize in a brief post.

Author Steven Sinofsky describes "going functional" at Microsoft, and says "No organization is purely functional or entirely unit-based, nevertheless in any given company of size (more than one product or more than about 100 engineers) there is almost certainly a dominant shape."

Sinofsky adds that while there's no obvious answer to "functional vs unit" for every organization, he does provide a few pros and cons. I'll attempt to summarize some of the core ideas here:


One product, one org. Sinofsky says "if you’re building one product then you just don’t really need “units”."

Better develops skills for each functional area. The "functional" org chart allows you to develop staff in the direction in which they are aligned. This is critical to an organization to grow its core strengths, especially as Sinofsky highlights that "the future of a technology company is never the current product, but the ability to lead technology change over many years and that only happens with depth of technology skills."

Easier to resource load balance. If you operate in a field that faces constant change, Sinofsky advises "A functional org is perfect for this because all the discipline resources are under one “roof.”"


Potentially diffuses accountability. When I worked in higher ed, we had a saying when referring to "academic IT" and "administrative IT": "One IT." It didn't matter what group you were in, but we were all in this together. But organizing your groups by function may spread out accountability.

Challenging to manage physically separate people. I've experienced this issue first-hand. It can be very difficult to manage people who are not sharing the same office space as you. Sinofsky agrees, and comments "a [geographically dispersed] functional org can be challenging because it pushes each of your functional leaders to become skilled in managing people from a distance."

People tend to feel less opportunity because there is “one” leader of a functional area. We all need to grow, and it's important for our star performers and future leaders to feel there is a place for them within the organization. Sinofsky agrees, and adds "there can be a feeling of limited opportunity “managing within a discipline” compared to “managing across disciplines”."
Sinofsky continues to compare and contrast Functional and Unit organizations. It's a long read, but worth your time if you are involved in defining your organizational structure.

Monday, March 13, 2017

Business and busy-ness

A friend and I do peer-coaching with each other, every few weeks. If you don't practice peer coaching, you should find someone you trust (and ideally outside your organization) and just talk for half an hour or an hour every month. Practice your coaching and mentoring with each other. Challenge each other. And help each other out. I find that these peer coaching sessions help provide clarify and allow me to refocus on my priorities.

This last session is a great example. In our last session, I related how things seem very busy right now, so my friend asked me what was going on. As I started to iterate the different things I was working on, I suddenly realized that I have over-stretched myself.

Here's a quick list of what I'm doing now:

  1. My day job (CIO)
  2. Founder and coordinator of the FreeDOS Project
    • Several projects associated with FreeDOS
  3. Director on the GNOME Foundation's Board of Directors
    • A few side projects for the Board
  4. Adjunct professor for an online class
  5. Writing articles for several different journals/magazines
  6. Writing a book about leadership
  7. Planning to write a book about usability in open source software
  8. Planning to write a book about management

Basically, I think my problem is I said "yes" to too many things. Someone asked me to take on a new responsibility, and I agreed to it before I really thought about how much free time I had available, and how much of that time I could realistically commit.

Take this as your reminder to stop and reflect on what extra things you've taken on. Have you tried to tackle too much? What can you do about it?

In my case, I'm planning to step down from the non-profit board when my tenure is up, in May. I'm also going to avoid teaching again, at least for a few years. And my book will have to wait until I have a little more free time to commit to it, while the future books will be put on "hold" until the first book is done.

Monday, March 6, 2017

On becoming a multi-dimensional leader

I recently discovered this great article from last year about "How to gain merit, regardless of your job function." The article begins by describing the ideal workplace, one organized as a kind of meritocracy: "In a meritocracy, leaders progress because of their demonstrated leadership abilities (not their formal titles). But how exactly do you gain merit in an organization using practices that aren't specifically related to your job function? "

The article then lists several key attributes for successful leadership in such a meritocracy. I thought this was good advice for any leader, and I wanted to highlight the attributes here:

  1. Listen to people
  2. Put yourself out there
  3. Maintain your moxie
  4. Cultivate diversity
  5. Own your mistakes
  6. Be mindful

I've discussed several of these leadership traits elsewhere in Coaching Buttons, but it's good to highlight them again here.

Monday, February 27, 2017

Finding the gems in your team

I'm away at a conference this week, so I wanted to share this brief link to a podcast interview from last year, at the CIO Talk Network.

The topic of the interview was "Discovering and Polishing the Real Gems In Your Team" and featured two leaders sharing advice about how to find and develop the next stars within your organization.

"A leader’s team may consist of different types of workers. For some of these workers, it’s just a means to an end, but there are others who believe that the work they do, matters. These workers demonstrate complete integrity and dedication towards their jobs and have a deep understanding of their organization’s goals. So how should a leader go about discovering and developing them?"

The interview features Helen Norris, Chief Information Officer, Chapman University and Tom Kolditz, Founding Executive Director, The Doerr Institute for New Leaders at Rice University.

I'm friend with Helen, and we peer-coach each other, so it was great to hear her advice in this interview.

Monday, February 20, 2017

The open leader

OpenSource.com recently posted a great about "open leaders" and "Why we need open leaders more than ever." In brief, the article discusses how leadership changed in the Twentieth Century with globalism and teams that were geographically displaced. And this new mode of working led to a new kind of leader: the "open leader."

The article makes clear that leadership can happen at all levels of the organization. And I agree! To be most effective, you need to develop your emerging leaders so people can "lead from the balcony" or wherever they are, to provide vision and drive strategic direction. From the article:
As organizations continue becoming more open, even individuals without "leadership" titles feel empowered to drive change. These organizations remove the chains of hierarchy and untether workers to do their jobs in the ways they best see fit. History has exposed 20th century leaders' tendencies to strangle agility through unilateral decision-making and unidirectional information flows. But the new century's leader best defines an organization by the number of individuals it empowers to get something done. There's power in numbers—and, frankly, one leader cannot be in all places at all times, making all the decisions.
The article provides a list of five attributes for the new "open leader":

1. Control
"Where the leaders of old are focused on command-and-control positional power, an open leader cedes organizational control to others via new forms of organizational governance, new technologies, and other means of reducing friction, thereby enabling collective action in a more efficient manner."
2. Communication
"The open leader seeks to engage an organization by sharing information and context (as well as authority) with members of a team."
3. Trust
"Open leaders embrace uncertainty and trust their followers to do the right thing at the right time."
4. Autonomy
"Where the powerful command-and-control 20th century leader is focused on some position of power, an open leader is more interested in the actual role an individual plays within the organization."
5. Empowerment
"Open leaders are focused on granting authority to members of an organization."
How do you compare to the new "open leader"?

Monday, February 13, 2017

How to write an email

Some people claim there's an art to writing an effective email. In my professional career, I follow these general rules for writing emails:
  1. Write email
  2. Delete most of it
  3. Click Send
I find brevity is often best. If I write too much, I may lose my audience. But there's a tipping point: you need to provide a certain amount of context. If you don't "set the stage" or don't provide enough background, your recipient may not understand your message. How little is "too little" in an email?

Let me draw on a few real-life examples. Outside of my regular job, I sometimes teach an online computer science class ("CSCI 4609") at a university. As an online class, we have a flexible class size, although we try to set the "reserve" limit at ten seats. After the first ten students sign up, you need a permission number. But I'll usually give a permission number to whoever asks for one. Usually.

The exception is for students who don't meet the pre-requisite. We require that students take another computer science course ("CSCI 2101") before taking mine. This provides a grounding for the material in "CSCI 4609." Such pre-requisites are not unusual at the university level. If you don't have the pre-requisite, you need to get a permission number from the instructor (me) so you can register for the class.

Let me use a few examples from this class to show how providing a bit of context can make your request more clear:

Too little information

You can imagine my confusion when I received an email like this one from a student who wanted to take my class: (not the actual email, but representative)
Hi. Please give me a permission number so I can register for your class.
Why did this student need a permission number? There were already ten students in the class, so the system might have prompted the student that the class was "at reserve" at the student needed permission to add the class. Or the student might not meet the pre-requisites. I need to know more before I can give a permission number.

In the first example, it's no problem to add the student; I don't mind more students in the class. But if the student didn't meet the pre-requisites, then I need to check that the student won't be in over their head. I want them to succeed in the class, but if they take the class before they understand certain basic concepts, they will find the class very challenging.

I responded to this student to learn more about their situation. Each email was equally brief, requiring us to exchange several more emails before I determined if the student should be added to the class.

Too much information

While it's challenging to respond to too-brief messages, it can be equally difficult to make sense of the small novels that some people send me. Here's another example from a student who wanted to take my class: (not the actual email, but representative)
Hello Professor Hall. I was looking through the catalog to find another class I wanted to take this semester and I saw your class, CSCI 4609. This is a really interesting topic and I'd like to take it. I talked to a few of my friends about it and they think this is something that will really help me after graduation, so now I really want to take your class. I was in the student center last night going through my course registration for Spring semester and I tried to add your class. The registration system is a little difficult to use, so I'm not sure what the message is trying to tell me. When I add your class I get a little red box that pops up and tells me I needed to contact you and get a permission number. But I'm a senior and this will be my last semester before I graduate. I have taken all my other CSCI classes already, and this semester I only have my capstone plus some classes for my minor. I have taken the interface class, last year with Dr. Smith, so I meet the requirements. When you have a moment, I need to get a permission number so I can finish registration in the class. I know we're out of queued registration but your prompt attention would help me to get the class for next semester. I would really appreciate it. Thanks so much!
Okay, wow. That's a lot of information. And the actual email I received was much longer than the sample I wrote for you.

This email is unclear and unintentionally buries the request in an avalanche of extraneous information. I don't need to know where you were when you tried to register for the class. I don't need most of the information here.

Reading long emails like this one seem like more work than reading other emails, because I need to parse the email to figure out what's really going on. Please keep them short for the sake of the person who will read it. Breaking up the email into paragraphs will also make the information more clear.

Just the right information

Let me edit the above email into a message that has just the right amount of information:
Hello Professor Hall,

I would like to take your class, CSCI 4609. I am a senior and have the pre-requisites, but the system says I need a permission number to take the class.

Can you send me a permission number?
That's much easier to read! Notice that the email provides a brief context to "set the stage" before making a simple request? The use of short paragraphs helps the reader to parse the email for the important points: The student has met the requirements, but needs a permission number from me. That's a clear request, and one that doesn't require any follow-up from me.

Monday, February 6, 2017

Above/Below The Line

Across my career, I have helped in several IT consolidations. We are also doing that now in my current position.

IT consolidations can be tricky to communicate. I find the biggest hurdle is explaining how an IT consolidation can help both parties. In most IT consolidation situations, you start with two groups that are managing up and down the "stack" of technology. A key goal is to leverage size and scale so each group takes on the role that is best suited to them, so you simplify the work and let people focus on their value to the organization.

For example, you might have a development team that creates web-based applications for the overall organization. To run their web-based applications, they need a web server, so they install and manage a traditional "LAMP" stack: their own Linux server with Apache, MySQL, and PHP. Except that in most instances, "manage" is an overstatement. The group needs to focus on maintaining the web-based applications they write, and the system administration of the Linux box, MySQL server and Apache instances tend to fall behind. Meanwhile, in another part of the organization, you have an IT infrastructure group that's dedicated to running and maintaining Linux servers, and MySQL databases, and Apache instances.

In examples such as these, IT consolidation makes a lot of sense. If you could peel off the "infrastructure" work from the development team, and move those to the IT infrastructure group, you gain efficiency. The development team can focus on writing new applications, and the infrastructure team can take on the system administration.

Unfortunately, not everyone sees IT consolidation in such plain terms. When you talk about moving part of someone's job into another group, emotions get involved and consolidation becomes more of a challenge than it is meant to be.

To help get around these issues, and communicate more clearly about the benefits of IT consolidation, I've developed a model that helps both sides understand how IT consolidation will work out to everyone's benefit. I call it "Above/Below The Line."

Like most of my examples, I prefer to communicate it visually. Applications come in different forms, so let's envision different examples of an application stack:

Local development

You might have the above example, where an in-house development team writes an application. This usually runs in some kind of framework, such as a web server or other container. Underneath that, you need an operating system, which runs on a physical or virtual server, with storage and network.

Business application

Many applications are instead delivered by a vendor that you just need to run somewhere. A classic example would be a client-server application, but you might have a vendor-delivered application running in a framework, similar to local development. Again, you also need an operating system, which runs on a server, with network and storage behind it.


Whether the application is locally-developed or vendor-delivered, many will require a database system to store structured data. In terms of the "stack," the data schema is served by a database engine, which runs on an operating system on a server. Network and storage support the overall system.
You should see some similarities here. Each system shares several components or "layers" in an overall "stack." You can draw these components in a simple diagram, such as this:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
As I mentioned, before IT consolidation, the development team might manage the entire "stack" in order to support their application. But post-consolidation, you need to separate what is "application" from what is "infrastructure" by defining roles. Having described the "stack," the next step is to define the separation of roles. Let me use color here: green to represent the application team and blue for the infrastructure team:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
I've added an obvious line to indicate where most organizations choose to separate roles. After IT consolidation, the application team operates "above" the line, managing the local application development, configuring containers, managing business rules for vendor-delivered applications, managing data and database software. In this model, the infrastructure team operates "below" the line, supporting the operating system, servers, storage, and network.

This is a great model, but it's also a simple model. In any realistic environment, I find you need to make certain exceptions. You'll always need some cooperation between the two teams. The purple line becomes more difficult to draw, because it's position will differ based on your environment. An obvious example is installing software; in most organizations, the infrastructure team may need to be involved to install applications. Although usually the application team can take things after that:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
And the opposite is sometimes true: the application team may need to do some things at the operating system level. For example, in a Linux system, the application team often is allowed to configure the web server software, and stop and start it using operating system rules (such as sudo). The line becomes less clear, but it is still visible:
Local developmentBusiness rulesData schema
Container (web, …)Delivered applicationDatabase software
Operating systemOperating systemOperating system
I created the "Above/Below The Line" model before Cloud was a thing. But Cloud applications are easy to fit into the diagram. Cloud applications are hosted externally, similar to vendor-hosted applications. So Cloud applications rely on the organization's network, but otherwise live completely "above" the line. An integration team (which might be the same as the application team) manages business rules in the Cloud application.
Local developmentBusiness rulesData schemaBusiness rules
Container (web, …)Delivered applicationDatabase softwareCloud application
Operating systemOperating systemOperating system
When I've shaped an IT consolidation discussion using this framework, I find we experience fewer miscommunications and less stress. The "Above/Below The Line" model helps both sides understand the roles involved after IT consolidation. The key takeaway is the infrastructure team does the "heavy lifting" of managing operating systems, servers, storage and networks so the application team can focus on what they do best: building and supporting applications that drive the business.

Monday, January 30, 2017


I've always loved audiobooks for longer than I knew the term "audiobook."

When we were growing up, my brother and I always read at a higher grade level. And to encourage us to read more, our parents would often read books to us. Our mom sometimes recorded herself when she read, so we could listen to the tapes again during down time.

During summer vacations, we would often take road trips to visit family. We're talking a really long car ride here, not a simple one-hour journey, but a cross-country trek. We lived in Minnesota, but our extended family all lived in Virginia and North Carolina. That's about eighteen hours non-stop, but well over twenty-four hours if you include stops. To keep me and my brother from getting fidgety, our parents played audio cassettes of radio programs. I developed a love of radio, from the original 1938 broadcast of War of the Worlds to comedy groups like Duck's Breath Mystery Theatre to other productions from National Public Radio (Star Wars, The Hobbit, Connecticut Yankee in King Arthur's Court, etc).

As an adult, audiobooks became a great way to pass the time during my hour-long bus commute to and from work. I started with the ever-popular Walkman to listen to audio cassettes, but later upgraded to an iPod. Listening to a great story made the ride go by more quickly. And most tapes were about twenty-five minutes per side, fifty for both sides, so when I finished side B, I knew it was almost time for my stop.

Audiobooks let me expand my genre. I enjoyed some titles that I probably wouldn't have read in print. The Silmarillion was interesting as an audiobook, but not usually what I would read. And I doubt I would have read the Harry Potter series in print, but they worked great as an audiobook series, read by the talented Jim Dale.

In 2010, I took a new job. Unfortunately, it meant a three hour commute to drive back to the Twin Cities for occasional meetings. And around the time I entered grad school, that became a weekly drive. But audiobooks helped pass the time. I lived by the books on my iPod. The long drive almost became something I looked forward to, because it meant listening to another audiobook.

Somewhere in there, I discovered Big Finish! They have the license to do new audio productions based on classic Doctor Who. But it's all new stuff. And as a big Doctor Who nerd, this was perfect! Big Finish appealed both to my love of audiobooks and to my classic fandom. My first story was Spare Parts, a Fifth Doctor and Nyssa story featuring the origins of the Cybermen, and immediately I was hooked! Over the years, I've picked up a majority of the Big Finish back-catalog. I try to stay current on the new stuff too.

They have a ton of spin-offs too, like I,Davros and UNIT and Dalek Empire and Cybermen and Unbound and Gallifrey and Counter-Measures and Jago & Litefoot. And other series, especially Blake's 7 and Survivors.

I still listen to a lot of audiobooks, but most of my collection is filled with Big Finish. Whenever I recommend audiobooks to folks, I always include a few Big Finish titles in the list.

So if you're looking for an audiobook recommendation, hit me up. I'm glad to recommend a few.

Monday, January 23, 2017

The XY problem

There's an interesting phenomenon in asking questions: we often ask help to solve the wrong thing. In certain circles, this is called the XY problem, summarized here:
  1. You want to do X
  2. You don't know how to do X, but you think you can get there by doing Y
  3. You don't know how to do Y
  4. You ask for help to do Y
The XY problem is asking about your attempted solution rather than your actual problem. But you won't get much useful help in asking to do Y, because you aren't really trying to solve Y. You're trying to solve X, yet you've invested so much time and energy on your possible solution involving Y that you forget to mention that X is the real problem.

As a result, folks may offer solutions to Y that technically work for Y, but don't help you with X. And that's not very helpful.

I see this happen across the board, in my work with open source software and in my professional career. Even I'm not immune to it; I may decide on a particular solution, and ask for help with that solution. But by not providing the full context of the problem I'm really trying to solve, others aren't able to help me that much.

Use your words. When you have a problem or make a request, tell people what problem you are trying to solve, and what solution you are currently chasing.

Monday, January 16, 2017

Don't check email in the morning

Many of us seem connected to our personal devices, like our phone. We check email, do Twitter and Facebook, read websites and blogs, watch videos… we do everything. Our personal technology has become part of our lives, like a habit.

And like a habit, I'll bet many have this bad habit: you check email first-thing in in the morning.

But checking email right away when you get up is ruining your work-life balance. You aren't staying separated from "work" when you are at home. And checking email in the morning can ruin your day, according to Michelle Gielan, former national CBS News anchor turned psychology researcher and best-selling author.

According to Gielan, even one bad email can set a negative tone for your day. And that rings true for me, certainly. I try not to read email over breakfast, but when I do, one bad item can put me in a poor mood for much of my work day.

If you must check email in the mornings, Gielan recommends instead to put yourself in the right frame of mind before doing work emails. Take a few minutes to send a positive email to someone you know well, like a friend or a family member. From the article:

After you send your upbeat email, move on to your regular routine of checking your work email or the news.

That two-minute message primes your brain to see everything in a more positive light.

“It will change how you process your day and how you process your email at 2 o’clock in the afternoon,” she says.

My best recommendation is to preserve your work-life separation, and avoid work email at home when you can. But for those times when you do need to check work email, Gielan's recommendations may help.
image: William Hook (CC by-sa)

Monday, January 9, 2017

On resource planning

As a young manager many years ago, I didn't really know how to manage people. I just didn't have any training for that. So when I needed to assign staff resources to projects, I did it ad hoc. I tried my best, but it came down to asking who was interested in a project, and making a selection based on who had the best availability.

The problem with ad hoc planning is that you aren't really planning. There's very little thinking ahead.

Later in my career, I worked with someone who was a professional planner. As a former project management consultant, this person really understood how to do project and resource planning. I learned from him that there are many ways to do thoughtful resource planning, and from him I derived a method of resource planning that has served me well these many years later. I'd like to share it with you.

If you do project planning or work as a project manager, this method may seem very familiar to you. But if you haven't done resource planning before, I hope this will be helpful to you.

You don't need a fancy tool to do resource planning, although there are professional tools to do much of the work for you. But a spreadsheet works well enough, especially if you are just getting started in resource planning. So let's do this example with a spreadsheet.

Start by thinking about a time frame. How far out can you do planning in your organization? If you're like me, one month is too short, and six months is too long. Things change more quickly than a six month time frame can accommodate, but not fast enough for a one month window. I use a three month time frame. This gives me a quarterly work plan.

There are 52 weeks in a year, 26 weeks in half a year, and 13 weeks in a quarter. So create your work plan by creating 13 columns, one column for each week. I also recommend you include the date of each week as a separate row—although for this example, I'll leave that out. Leave a few columns to the left; we will fill these in later:

Now, think about the work that you will need to get done over the next quarter. What work does your organization need to get done? What are the priorities from your leadership? What are the major projects? Put these on separate rows in the first column.

Don't forget that support activities also count here. For example, you may have systems administrators who need to keep servers running. Same for network administrators supporting your network. You need to include these too.

Once you have the major projects, determine how the projects break down by tasks. A project consists of many steps. What are the components to complete the project? List the steps in the second column.

Then, identify the resources you have available. What projects are they best suited for? What are their skills? Where can you best direct their energies? Who would be the best contributor for each project? Don't forget that only very small projects require just one person; most projects will require more than one contributor. List the people for each task in the third column.

In this example, let's assume two "infrastructure" team members (John and Jane) and two developers (Jill and Jack). As we start the quarter, the developers are starting a new project (Project1) while they prepare to deploy a previous one (Project2).

As you identify new projects and tasks, keep the spreadsheet organized. In this example, see how separate projects start on their own row. Tasks are matched with a resource. I've kept my example somewhat simple by not providing much detail. If you were writing your own resource plan, you would likely need to fill in more information about the project and tasks.

Look ahead by weeks and consider how long each task will take. If this is your first time building a resource plan, you might "block out" some time by filling in each week with a color that you can go back to later. Let's do that for the example. I'll block out some time. Note that the support tasks should be blocked out for the whole quarter, but other tasks in other projects might take different amounts of time.

From here, you need to assign time or "effort" each week to every person working on every task in each project. You can do this a few different ways. Professional project managers sometimes prefer to use a four-day work week, where you always assume one day is "lost" to "overhead" (usually meetings). I prefer to use a five-day work week. I find my staff understand the five-day work week better if they can build in their own "overhead" and see where their time is going. This also allows some flexibility. For example, developers may need to attend more meetings for project planning, etc. Let's assign time to each project with the assumption that John and Jane attend fewer meetings than Jill and Jack.





Look at every column, and make sure the total time for any one person adds up only to 5.0 every week. There are only five days in each week, you can't expect your team members to work more than five days. In the above, Jane is over-committed on "server" and "database." Similarly, Jill and Jack are over-committed across "Project1" and "Project2."

When considering the balance of time, I prefer to use a few simple rules: The smallest increment of time allowed is 0.5 days per week. That's four hours of work time, and I find you cannot really plan for time less than four hours per week.

As you balance the time committed to each project, consider the work load. For example, Jane's dual responsibilities as server administrator and database administrator may not require equal time. Perhaps she spends most of her time maintaining the server.

And don't forget about vacations and holidays. Everyone needs time off, and you need to plan for that. Build your holidays into your work plan from the beginning. Ask staff to estimate their upcoming vacation time. While folks might take an unplanned day off here and there (or be out sick) you can still plan in advance for extended absences such as a long vacation.









As you can see in the work plan, Jane plans to divide her time between "server" and "database" tasks. For the first eight weeks of the quarter, Jill and Jack each will spend some time on analysis and design for "Project1," and the remainder of this time doing testing for "Project2." See under "Project2" how Jack ramps down on testing at the same time Jill ramps up, because of his balance of responsibilities.

Also, Jack gets to turn a holiday on week 2 into a four-day weekend in week 3, while Jill takes an extended vacation during weeks 9 and 10. John takes the whole of week 8 as vacation, and Jane takes all of week 11. When each person is out, notice that their time on other projects also needs to be redistributed.

That balances the time assigned to projects. No one gets overloaded. And everyone gets to take their vacations. The staff can be productive, while the manager is able to plan for their work.

With that, you have the start of a quarterly resource work plan!

You can add other features to this work plan. Here are a few ways to extend this:

Total time

As you build your work plan, it quickly becomes cumbersome to add up everyone's time each week, and ensure every person is allocated "5.0" days per week. Let the spreadsheet do the work for you. Look up the =SUMIF() function to make this easier. The =SUMIF() function is a standard spreadsheet function to add numbers from a column only if a key matches one in a list. In calculating total time, the key is the name of each staff person. I also use automatic formatting in my spreadsheet to highlight the total in a different color if the value is less than, equal to, or greater than "5.0." This helps me to quickly identify where staff are over-committed as we build the work plan.


As you progress through the quarter, how do you track when people actually work on projects? When I "borrowed" the work plan spreadsheet from my colleague, he used separate tabs in the spreadsheet for staff to report time. Entering time into the spreadsheet required staff to track hours worked against each planned work item, and provide an estimate to completion. This sounds great, but ended up being very confusing, especially for folks in a primarily "support" role. Later, I asked my teams to report their status using a simple metric: don't change the numbers in the work plan, but highlight each cell to indicate when you worked on something. Highlight in green if your project is progressing well, yellow if you encounter issues that might put your project behind schedule, and red if the project is at risk. Then I would review the spreadsheet every week as part of my staff meetings to see how things are going. If I saw any yellow or red for the previous week, we would go over that and talk about issues and how to move things forward.

Unplanned work

You can't really plan for unplanned work, but sometimes things just happen that require staff to drop everything and make some work item their number one priority. In higher education, the dean might ask us to work on a special project. This was unplanned work, and it certainly had an impact on our time. To account for unplanned work, I would add a few rows to the bottom of the spreadsheet, one row per staff member, and reserve this row for unplanned work. If you worked on an emergency project that wasn't on our list, you would record the time worked in your "unplanned work" row, and use a spreadsheet cell comment to indicate the unplanned work item. If this unplanned work impacted another planned work item, the staff member would highlight that other project's status with yellow or red to flag it for the manager. This ended up being a good balance of reporting time without over-burdening staff to fill out a weekly status report.

Roll-up reporting

Sometimes it's helpful for a manager to provide a "roll-up" report of how their team spends their time. This kind of "roll-up" requires adding a new column to the work plan to categorize the type of work. I borrowed from other professional project planners and developed a "code" to represent the type of work:
AN Analyze: Time dedicated to understanding a project or doing background work about the project.
DE Design: Designing a solution.
BU Build: The creation of a system.
TE Test: Time dedicated to testing a new system.
DP Deploy: Rolling out a new solution.
P Project: Use this if your project doesn’t use defined phases like Analysis, Design, Build, etc.
PM Project management: Usually reserved for managers who need to report time.
CF Change-fix, or production support.
NP Non-project time, such as vacations and holidays.
UW Unplanned work: Time spent on emergencies or last-minute important work requests that were not planned. By definition, do not plan for UW.
Once you have a code entered for each task on the work plan, you can create a simple roll-up report to show how time has been allocated. Again, let the spreadsheet do this work for you. The =SUMIF() function can use the code as the key to generate the total time for each code. This lets you build a matrix to calculate the total time spent each week for each type of work.