Monday, December 26, 2016

Top ten from 2016, part 2

I'm doing a year in review, and re-sharing some of my favorite articles from 2016. I posted the first part of the list last week. Here is the second set.

6. IT organizations must adapt or die
Think about how much things have changed since that application first went live in 1998. Back then, most of us used desktops. Laptops were available, but in the company where I worked, only the CEO and CIO used laptops. They were too expensive for the rest of us. Cell phones were common, but they were big, blocky affairs that only made phone calls. 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.
7. Career ladders
A few years ago, I served on a committee to identify new career ladders for our IT teams. This work originated with a document I wrote about how to "level set" the compensation and seniority for our operations and infrastructure staff, many of who had joined our team as part of IT consolidations from different parts of the organization. In that document, I set a new career progression, from "junior" to "staff" to "senior" to "team lead," with compensation ranges for each. This document was going to be the basis for a re-organization of my teams. I have since used this career ladder concept as a basis for organizational planning. The document provides a simple overview of technology teams and how job areas are aligned and related. Our work was expansive. We defined eight separate career tracks, with different levels within each.
8. How to lead an affinity exercise
My job is to provide leadership to my IT organization, but often that leadership involves soliciting ideas from a larger group. You might lead a governance group, or you might meet with your entire team as part of an annual meeting. It's good to leverage meeting opportunities to caucus the group and tease out common ideas. But how you solicit ideas may differ depending on the size of the group. For small groups, I often use a SWOT exercise. In larger groups, I rely on some variation of an affinity exercise.
9. Good and bad bosses
We've all had good and bad bosses. Hopefully, you've had more good bosses than bad bosses. Nothing can sap the energy from you like a boss you don't like. On the bright side, a good boss makes you feel valued and excited to come to work every week. No matter what bosses you've had, I hope you learn from them. What best practices do you observe that you can adopt for your own management style? What bad habits do you notice that you should avoid? In this light, I'd like to reflect on several managers I've had over my career, both good and bad.
10. Yes but no
A former colleague from the University of Wisconsin-Madison once showed me how to build trust within teams through the "Yes and" approach. When you say "Yes," you provide agreement. If you build on that and say "Yes and," you lend support.I prefer "Yes and" statements. They are positive, reinforcing conversation tools that build trust. In contrast, "Yes but" statements erode trust. Some people seem to think it's the same as "Yes and," but it's not. "Yes but" is at best a way to stay on both sides of an issue. At worst, "Yes but" is a negating statement. The "Yes but" statement says "Yes, I agree with you, but not really."
That's it for 2016. Happy New Year!

Monday, December 19, 2016

Top ten from 2016, part 1

2016 has been a great year. I was fortunate to take on a new position that I love, and I moved back to the Twin Cities. As the year winds down, I like to reflect on some of my favorite articles. Here are my top ten, in no particular order:

1. Advice for new managers
When I started work all those years ago, a colleague gave me a little book filled with aphorisms about life in the office. At first I thought it was a humor book, with comments like "When the office secretaries say they are cleaning out the fridge of anything older than one month, it is time to grab your bottle of salad dressing and put it on your desk." But in the first month of my first job, I quickly realized the truth behind these pithy observations. When I later became a manager, I wished someone had shared similar wisdom with me about how to act as a new manager. So I would like to share a few brief observations that may help first-time managers.
2. Why executives use Powerpoint
In my new CIO role, I'm in a much larger organization. I'm always meeting with people. That in-person contact is very important to me; I like to build relationships with those I work with, as a way to get things done. When I'm not in a one-on-one meeting, I'm usually in a committee meeting or a steering committee meeting or a governance meeting. These are important meetings too; they are the mechanics of projects. But the side-effect of all those meetings is that I rarely have time to write documents. So instead of writing documents, I prepare a Powerpoint slide deck, and I speak to those issues when I'm making my presentation.
3. Five levels of performance
At what level is your organization performing? Are you exceeding expectations? Falling below expectations? Or just meeting the expectations? Some experts refer to four levels of performance, originally credited as the "Four stages of competence." Others refer to five levels, with the fifth level indicating either an ability to instill performance in others, or a "super-performance" level. I prefer the latter. These five levels of performance apply to both individuals and organizations.
4. Understanding risk
Throughout my career, I have tried to take a risk-based approach to actions and decision-making. This has become more important to me as a CIO. Understanding risk is an important part of driving change. If you understand the risks, you can decide which risks you can accept and which you cannot. In doing so, you avoid "analysis paralysis" where you continually evaluate options without actually choosing a direction. By taking a risk-based approach, some options become obvious.
5. About governance
No matter how IT is organized, you must always consider how IT is governed. How do you ensure that IT is meeting the needs of the business? This governance can be formal or informal depending on the relative maturity of the business and of IT. But at some point, IT needs help to "vet" IT decisions to best serve the needs of the business. Governance can take on many forms, but the general process is that someone listens to business needs, and a governance group prioritizes requests and creates projects to execute them.
I'll post the remainder next week.

Friday, December 16, 2016

Leadership lessons from unusual places: Project Runway

With this post, I'm wrapping up a week-long recap of my presentation "Leadership Lessons from Unusual Places," from last week's Government IT Symposium.

Coaching and mentoring are very important to me. I named my blog "Coaching Buttons" because of the importance of coaching. The name "Coaching Buttons" refers to those informal moments when you can provide some coaching to one of your team.

Of course, it's better to find separate time for proper coaching. And there's a great example of coaching in Tim Gunn from the TV reality show Project Runway. If you haven't watched the show, it's a reality show where fashion designers compete. Because it's a reality show, there's an elimination every week. But I think it's fair that designers get eliminated based on merit, not personal bias from the judges.

Each episode has the same basic structure: the designers receive their challenge, they shop for materials, then they have one or two days to create a fashion garment. It's a very short timeframe for the designers to create and execute their visions.

About half-way into each episode, Tim Gunn arrives to provide some coaching to the designers. Let's watch this brief clip and observe Tim's coaching style:

I think this clip is typical of Tim's coaching on the show. Note how Tim asks probing questions, and offers observations. He doesn't "push" a viewpoint or agenda on the designer. It's up to the designer to execute their vision.

Tim doesn't dictate a resolution. In other episodes, it is extremely rare for Tim to make a direct suggestion for what to do with the design. In this clip, I observe the designer answering questions with an implied "question mark" at the end of his answer, possibly to elicit approval or direction from Tim. But Tim doesn't respond to that. He doesn't force an idea.

Through his probing questions and observations, Tim lets the other person explore options and find their own way. This clip is one example of that. I also tried to find another great example from the show, but for the life of me I can't find it on YouTube. In that coaching moment, Tim helped a designer who felt "stuck" on his design. In response, Tim suggested they look at the design from a different angle. "You are literally too close to this." So they went to the other end of the work room and looked at the design on the mannequin. Having some sense of separation helped the designer, who immediately saw the problem and had an idea for what to do.

When we provide coaching, we need to avoid pushing our own agenda onto the discussion. Let the other person explore new ideas, let them make the discovery. If you think you know the "answer" and offer your own solution, then whatever they do is your "fault." They won't feel any ownership in the decision. Instead, ask questions that allow the person to work through a problem and work out the issue on their own terms. When they return to work, they will have ownership in what they are doing.

Thursday, December 15, 2016

Leadership lessons from unusual places: My Little Pony

I'm continuing my recap of leadership lessons from unusual places, from one of my presentations at the Government IT Symposium last week.

In this leadership lesson, we can learn about building relationships from My Little Pony Friendship is Magic. What a wonderful show! It's full of lessons about how to build and maintain relationships. In fact, the whole show is nothing but about how to build and maintain relationships. Because friendship really is magic.

Relationships are the currency to getting things done. Think about how many times you have been stuck on something, and you've needed to call someone for help? As a manager or director, I'm sure you've had to call another work group or another division and say, "I'm having a problem working through X group, can you give me a hand here?" or "I'm trying to do X, but I'm getting stuck, can you help out?" or "Looks like I made a mistake here, can you help me smooth things over?" I think most of us have had conversations like that more than once.

The key in those conversations is relationships. You know someone who can help, and you reach out to them. Because you have an existing relationship with that other person, they feel a connection and are motivated to help. And you can really only ask those favors from people who you know well. You can't ask that of people you don't really know, or people you just met. If someone you don't know just came up to you and asked, "I'm trying to work with this other group, but their manager is stonewalling me, can you help me get around that?" then that would be weird. You don't know the person who is asking the favor, so it's odd that they would ask you for help.

Think about your social network. I like to imagine it like a bullseye target, where the closer you are to the center, the "closer" your relationship to me. The center circle is the "circle of trust," the people you might go to for completely confidential advice. These are the people you might ask for help if you were looking for a new job. The next circle contains those people who would help you with a favor. Outside that is the "parking orbit," people who are not very close to you, but with whom you are friendly; you might see them in the hallway or by the elevator, but not interact with them very much. And if you aren't in any of those circles, I call them "potential new friends," people I haven't met yet.

You can arrange your social network even further. Think of who are your personal friends, versus your friends at work. Who are your mentors, the people you look to for inspiration? And who are your peers, people with whom you interact but who are neither "personal" nor "work" friends?

You need relationships to get things done. Relationships are that important.

But how do you build relationships? Just remember the four I's of relationships:

  1. Initiate
  2. Inquire
  3. Invest
  4. Inspire

Start by meeting a new person, and reaching out to them (Initiate). Start looking for connections by asking questions (Inquire) and getting to know the other person. Over time, as you become closer, you Invest time in your relationship. This builds bonds. Eventually, you may find you can use your relationship to Inspire the other person to do great things.

Let's go to My Little Pony to observe the first two I's of relationships: Initiate and Inquire.

Here, you can see Twilight Sparkle using Initiate ("Hello. My name's Twilight Sparkle") to start the conversation, then Inquire ("What's your name?") to prompt the other person. She also asks follow-up questions to get to know the other person. Despite Fluttershy's introverted tendencies, Twilight Sparkle reaches out to get to know the new pony, making sure she heard the name right, and commenting on Fluttershy's birds in the tree.

Twilight Sparkle only has time for the first two steps. The third step, Invest, will happen over time as Twilight Sparkle continues to renew her friendship with Fluttershy through activities and adventures. That's just part of the show. Over time, Twilight Sparkle can rely on that relationship to inspire Fluttershy to do great things. That's also part of the show.

You can use the same method of Initiate, Inquire, Invest, Inspire to build your own relationship networks. The more people you know, the better you can navigate your organization and get things done. But don't let your relationships grow stale; fins opportunities to renew your friendships. If you call from someone in your relationship network, take a few moments to catch up before getting down to the task at hand. Or simply call or visit that other person, just to say hi and see what's up. These short moments help to build up your relationship currency.

Wednesday, December 14, 2016

Leadership lessons from unusual places: Disney's Mulan

Continuing my recap from last week's Government IT Symposium, I wanted to share a few insights from my presentation about "leadership lessons from unusual places."

One other resource I shared was Disney's Mulan. This is an entertaining animated feature about one woman's brave decision and personal journey to protect her father and—at the same time—save China from the invading Shan Yu. It really is a wonderful film and I don't want to distract from the message of the movie or the performance of the actors.

But when I watched Mulan, I immediately realized the leadership qualities of Shan Yu. It turns out that Shan Yu is very adept at coaching and mentoring. You can see this demonstrated in several moments throughout the film, whenever he interacts with his warriors. This scene is particularly instructive:

Watch that clip carefully and you'll learn a few tips on coaching from Master Shan Yu.

Note how Shan Yu uses this opportune moment to coach his staff. He finds a doll, and asks his team leads for what they can learn by examining the doll. They each provide their own insight that fills in a larger picture: the doll comes from a village high in the mountains, and the Imperial cannon brigade is there too.

As the viewer, we don't know whether or not Shan Yu knew this ahead of time. If he does, Shan Yu is careful not to insert his own point of view before asking the opinions of his team. He simply asks, "What do you see?" and lets others fill in the blanks.

Shan Yu uses this "coaching moment" to engage his team. His comments are brief, memorable, but not overpowering. Shan Yu is able to offer his own opinion (and decision to return the doll) without discounting the opinions of his team leads. From what we see in the movie, I think we can assume Shan Yu has taken advantage of other coaching moments to help his future leaders develop.

I like to refer to these "coaching moments" as "coaching buttons." These are the moments before and after a meeting when you find yourself chatting with one other person on your team. Or that moment in an elevator when it's just you and a staff member. Take these moments as gifts, and leverage them to do coaching. "Coaching buttons" are wonderful conversational gifts. 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.

Be like Shan Yu. Use these moments wisely and turn them into coaching opportunities.

Tuesday, December 13, 2016

Leadership lessons from unusual places: Pulp Fiction

At last week's Government IT Symposium, I talked about leadership lessons from unusual places. I wanted to share another source for learning about leadership. Specifically, leading small group discussions.

Let's watch this brief clip from the movie Pulp Fiction. This is from the beginning of the movie when Jules (Samuel L. Jackson) and Vincent (John Travolta) meet with some business partners of their employer. It's a meeting over breakfast.

In the Symposium presentation, we examined this clip through a new lens. Don't look at it as "gangster meeting with thugs," but rather "manager meeting with business partners." What are some lessons you can take away from this scene? I think you can learn a few things about leading a small group discussion.

Find commonality. Note how Jules immediately makes a connection with others in the room. He is clearly an extrovert, and can find opportunities to make small talk. But you don't have to be an extrovert to do this. Follow Jules's example to make small talk, and put others at ease.

Lead with clarity. Early in the conversation, Jules asks a few clarifying questions to set context and make sure everyone is aware of the purpose for the discussion. "Do you know who we are?" and "You do remember your business partner, don't you?" serve as a kind of introduction and help people to get on the same page.

Observe cultural norms. I used to work in higher education, as campus CIO for a small university. I remember that a key part of our campus culture was based on food. It seemed everyone brought food to meetings. It was just something you did. So I started to bring food to meetings, too. This helped to fit the cultural norm. It also helped to smooth over difficult meetings. So if you're going into a meeting to discuss a difficult topic, and especially if that meeting is first-thing in the morning, bring some doughnuts or muffins. Having food can help put people at ease.

Get into character. Did you notice what Jules said to Vincent at the very beginning of the clip? "Let's get into character." A colleague of mine often says, "Leadership is a performance." Sometimes you need to assume the character traits you want others to see. Do you need others to see you as collected and calm? Observe your body language and what messages you send when you attend your next meeting. How you project yourself says a lot about you; use that. Another colleague of mine advises to pause for fifteen seconds before you walk into a meeting. This is especially important if you are a few minutes late for the meeting. Another few seconds won't make a difference, but how you appear in the meeting will. If you appear unnerved (because you are late to the meeting) that may change the tone of the discussion that follows. So take a few moments to "get into character" before you join the meeting.

Monday, December 12, 2016

Leadership lessons from unusual places: Breaking Bad

I wanted to share another set of leadership lessons from my presentation at the Government IT Symposium.

I like to find leadership lessons from a variety of places. I think it's more interesting to look for leadership lessons in unusual places. If you look for leadership lessons from expected places, it's boring. If someone came you to you and said "It just watched that movie about Steve Jobs, and I learned that to lead a technology company you need to have passion and be driven to innovate," then you would reply "Of course, that's the point of the movie." That's boring. Instead, I like to look for leadership lessons in unusual places.

Let's take the show Breaking Bad. It was a very popular show, and if you haven't seen it, I recommend you do. In brief, the show is about an instructor who leaves academia, meets a former student, and gives remedial chemistry lessons to him while they entrepreneurially create a small business which they then grow. I think that's a fair description of the show.

And if you've seen the show, I hope that helps you to look at it from a fresh perspective. That will help in finding leadership lessons.

Let's examine a few key characters from the show:
  1. Walter
  2. Gus
  3. Hank
  4. Hector

While the show has a lot of characters, these four exhibit some great leadership traits.
When Walter leaves academia, what's the first thing he does? He teams up with Jessie. Walt knew he couldn't go it alone. Sure, Walt had the technical background they needed, but Jessie had already established several relationships that they would need to bring their product to market. Everyone needs to be part of a team.

And that's true whether you're working on an IT project, coordinating a campus-wide effort, or cooking a batch of meth in a dilapidated RV in the deserts of New Mexico.

While it's important to partner with someone who works well with you, be mindful that you select someone who brings a fresh perspective. If your partner carries the same opinions that you do, you'll fail to identify issues before they become problems, and you'll miss valuable opportunities.
The photo is from the first time that Gus meets Walter. It's a key moment in the show. And what can you say about how Gus approached Walter? I think you'll agree that Gus was very careful. Gus wanted to be sure Walter was someone he could work with, and that Walter wanted to work with him.

A colleague once related to me that hiring new people onto a team is a half-million dollar decision, and you need to treat it as such. Think of it this way: in higher ed and in industry, expect to spend about $100,000 per IT professional per year in salary and fringe (in most metro areas). Hire the wrong person, and IT managers may spend several years trying to "fix" the person they hired before deciding to end the relationship. And in the meantime, your team will experience "collateral damage" as more experienced members try to repair mistakes caused by the problem person.

Be like Gus. Whether he's hiring a fry cook in his fast-food restaurant or a partner in a new business venture, he builds a solid understanding of who he's dealing with. Large or small, Gus is careful to hire only the right people for his team.
Throughout the series, Hank is trying to catch bad guys. The photo shows Hank in his "war room" where he mapped out connections in an effort to identify the ringleader of an underground group. One thing you can say about Hank is he was meticulous in his planning. He examined details closely. And this paid off for him later, when he finally connected the dots to make a great discovery.

Take a lesson from Hank. Take care to plan out your vision and clarify your team's role in executing that vision. Apply proper methodology to your project planning, such as detailed effort work plans or simple Gantt charts, to ensure a smooth delivery. Map out any obstacles in your way and get people together to identify how to work around them.

But leave some flexibility in your planning. There is such a thing as becoming too focused. Avoid becoming overly attached to an idea so that it prevents you from seeing other possibilities and alternative outcomes.
I think we can all agree that Hector was a determined man. He carefully weighed his decisions, and having decided on a direction, he committed himself. I selected this photo of Hector because it shows him while he is making one of these important decisions. Walter comes to Hector with a proposal, and asks for Hector's help in getting out of trouble. Walter doesn't have a prior relationship with Hector, but he is persuasive nonetheless. Hector considers the offer, and is "all in." Because of Hector's commitment to the agreement, the season ends with a bang.

When you make a decision or decide on a course of action, there shouldn't be any doubt that it's the right thing to do. Balance your options, and weigh the benefits against the risks. And when you move forward, put all your energy into it. If you hold back, you aren't really committed.

Look at Hector. When Walter approached him with an opportunity, no one could argue he didn't commit himself to the deal. He evaluated the options, and was all in. Be like Hector. Ring the bell of success.

Saturday, December 10, 2016

Leadership lessons from unusual places: Star Wars

At Symposium this year, I gave one of my favorite talks: leadership lessons from unusual places. I sometimes like to find leadership lessons in unusual places. Looking for leadership lessons through the lens of unexpected sources can be interesting and insightful. In this session, we learned about leadership from various sources including: Disney's Mulan (coaching), Breaking Bad (commitment, hiring), Star Wars (taking on a new role) and My Little Pony Friendship is Magic (relationships).

While I've written about these leadership lessons elsewhere in my blog, I'd like to share them again here.
Let's start with my original example: Star Wars: Return of the Jedi. When I first looked for leadership lessons from unusual places, I started with Star Wars as my example. Pretty much everyone has seen Star Wars, so it makes for a good starting point. We all have that common ground.

But as we look for leadership lessons here, I need you to use a different lens. Don't look at Star Wars as space opera. Rather, look at it as an example of leading through change.

First, you have the Emperor. But before we can discuss him, we have a "news flash." It appears the Emperor has died in an industrial accident. While touring the "peace moon" known as the Digitally Enhanced Array, Troop Habitation, Satellite Transmitter And Receiver (aka "DEATHSTAR") the Emperor has met his untimely end. We don't know much at this time, but we can assume leadership will move down to the next "rung" on the ladder: Darth Vader.

Vader has a very similar leadership style to the Emperor. He's callous, officious, and sometimes micro-managing.

Now assume the persona of someone providing advice to Vader during this difficult transition in leadership. What advice would you give Vader to help him in his first 100 days?

In my Symposium session, I asked the audience to share their advice. People recommended Vader communicate his vision to the admirals and other leadership within the Empire. Understand the organization, learn how they operate. Maybe do a SWOT exercise to identify focus areas. Overall, he should share his broad themes early.

But wait! We have another "news flash" from the forest moon of Endor. It turns out Darth Vader also perished with the Emperor, at the hands of Luke Skywalker. Effectively a coup, Skywalker will now assume the mantle of leadership. We don't know much about Skywalker, but as a Rebel we know that he is the polar opposite of Vader and the Emperor; we can assume his leadership style will be quite different, as well.

Consider your persona of someone providing advice to Skywalker during his transition to the seat of power. What advice could you give to Skywalker to help him take on this new leadership role?

At Symposium, I asked the audience to give their advice. People responded that Luke should meet with the existing leadership to help them understand who he is, and what he wants to get done. Talk about his leadership style. Communicate broadly, and build relationships. Overall, people recommended that Skywalker share themes about his transition so others knew what to expect.

Consider the recommendations. Read them again.

People gave the same recommendations for leading through change regardless of leadership style. We expect Vader and Skywalker to have very different leadership styles, but how they lead through change is the same:

  • Communicate your vision
  • Understand the organization
  • Identify focus areas
  • Build relationships
  • Share broad themes early

It doesn't matter what end of the leadership spectrum you are at, you should follow the same guidelines when leading through any transition.

Friday, December 9, 2016

Disaster Recovery Planning at Symposium

This year, I was proud to be part of the Minnesota Government IT Symposium. One of my roles as a committee member was leading an all-day disaster recovery and business continuity planning "tech jam" workshop. Thanks to Bill Bushey, Kelly Clausen, and Cat Beltmann for helping to plan and execute the tech jam.

About twenty IT professionals joined us on Tuesday to compare notes about disasters, discuss disaster recovery planning, and to design architectures to respond to different disasters. On Wednesday, I shared what we learned in a 90-minute "report out" presentation during Symposium. I'd like to share a brief summary of that here.

First, what is disaster recovery compared to business continuity?

In the simplest definition: disaster recovery is what you do to recover your system from a disaster. Business continuity is what you do to keep conducting business while others recover the system.

In most organizations, IT focuses on the disaster recovery, and the business units focus on the business continuity.

When we talk about disaster recovery, most people immediately think of the "smoking hole in the ground" scenario. They imagine examples where the data center building is engulfed in an inferno or demolished by a tornado. In fact, disasters can be large or small.

In the workshop, we led a small group breakout to discuss different disasters we had all experienced. We heard examples like a database administrator not checking the status of a backup before deleting a database to upgrade the database software (in fact, the database backup had failed). Or of building management conducting a fire alarm system test, and accidentally shutting off all power to the data center. Or a water leak from an overhead sprinkler system that damaged several racks of systems in a data center. Or construction workers who accidentally cut into the only fiber data connection for the data center.

So a disaster recovery plan needs to accommodate different types of disasters, different scales from large to small. In the best case, organizations can design an architecture for their systems that remains flexible to an outage. The best disaster recovery plan is one that doesn't require people to get involved. But if you aren't able to have systems automatically "fail over" during an outage, you want to have a plan documented beforehand about how to recover your systems.

Folks divided into four working groups, and spent the rest of the day designing an architecture and documenting a response plan for different scenarios. One group discussed how to recover from partial data center damage, and another group prepared a plan for a new property tax system. A third group designed an architecture to extend flexibility for a network in the face of a possible ISP outage, while a fourth group used the workshop to outline an actual disaster recovery plan.

For details from the four working groups, please see the materials we shared from the Symposium. We captured the work of all the working groups and have made the information available to Symposium attendees. We encourage you to use this as a starting point for disaster recovery planning in your own IT organizations. Let this work help you get a jump start on planning for disasters.

At a high level, here are several key "take-aways" from the four working groups:
1. Partial data center damage
Identify critical people and vendors.

In a disaster, you will need to immediately reach out to technology folks to respond to the disaster, and vendors to help you get back to business quickly. Your next disaster may not be conveniently timed to occur during working hours. Make sure you have copies of contact information available off-site.
Network is important for business.

With so many organizations using Cloud and vendor-hosted applications, the network is key to your business. If your partial data center outage impacts the network, your users may not be able to access these remote systems. Also consider authentication and other components to your network.
Maintain a warm site.

If possible, you should implement dual "hot" sites where you run production applications and systems from two or more sites.
Identify critical systems and applications.
Conduct a risk analysis or other determination to understand which systems are truly your most critical. Create disaster recovery plans for these systems first. For example, most organizations can let "development" or "test" systems wait a few days while you bring up production systems.
2. Property tax system outage
Are your RTO and RPO realistic and achievable?
How quickly can you recover a system, and how old will your data be when you get it back up? these address two important factors in disaster recovery planning: RTO (Recovery Time Objective) is how long it will take to recover your system, and RPO (Recovery Point Objective) describes the "age" of the data that you can recover.
Understand the impact.
What is the cost of an outage? In this scenario, the working group was able to quantify some numbers. For example, the interest on $100 million over three days. Use the cost of an outage to help you justify additional infrastructure.
BC and DR can sometimes intersect.
In most instances, disaster recovery is performed by the IT team, and business continuity is the responsibility of business units. But depending on the application, note that the "players" for these may overlap.
Design for redundancy and failover.
Where possible, create an architecture that remains flexible in the face of an outage. In one example, you might run production systems from two different data centers. But as you design "failover" into your architecture, look for single points of failure and address them.
3. Network and ISP
Network is business critical.
This was a repeated theme throughout the day. Many organizations now outsource applications, and leverage Cloud and vendor-hosted systems. While this simplifies your IT, it means the network becomes even more critical to your operations.
Identify single points of failure.
Another repeated theme from the workshop. As you design your architecture, consider what systems are dependent on other systems. Watch for any single points of failure.
What is your upstream's DR plan?
Be mindful not to be lulled into a sense of security when outsourcing applications and services. Just because you have outsourced part of your systems to a vendor or other upstream provider doesn't mean you can ignore disaster recovery planning. Discuss disaster recovery plans with your upstream vendor to understand how they will bring your applications and data back online in the face of a disaster.
4. Disaster recovery planning
Identify systems and inter-dependencies.
As you create a disaster recovery plan for an application, look closely at the systems it connects to. What inter-dependencies exist? How does your application rely on other systems and applications?
Document the architecture.
You can advance a disaster recovery plan very quickly simply by documenting the architecture. Make this a group exercise, to sketch how each component of an application runs on different systems, and how those systems are connected.
How do you go back to normal?
It's tempting to focus only on the actual "recovery" portion of a disaster recovery plan. For example, your plan may require moving production to a "test" server. But you can't run production on the secondary system forever. Having "recovered" on the test system, how do you plan to go back to a normal state?
Analyze risk to find critical systems.
Use a risk analysis method to identify which systems and applications are the most critical to your business. One way to do this is to break it up into components: the likelihood of a failure, and the business impact of the failure. The combination of these components determines the criticality of the overall system.
I thought it was great that two of our working groups used Tuesday's workshop to carry forward work that is currently underway in their organizations. If you are a local CIO who sent staff to this workshop, your teams came away with actionable results.

Friday, October 21, 2016

I'm working on a project

You may be wondering why I haven't posted in a while. That's because I'm working on a project: I'm creating an ebook!

The new ebook will be titled Coaching Buttons and will be a collection of original essays from my "Coaching Buttons" blog, including some interesting articles from my archived "Jim Hall's Blog" blog (before moving to Blogspot).

To give you an idea how much extra work this project requires: I printed out all my blog posts, from both blogs, with each essay starting on a new page. That's just over 1,100 pages! I'm sorting through those now. Some of my old articles were "kudos" for staff or one-off posts that highlighted someone else's work. I'm sorting those out; my ebook will only include original essays.

No word yet when I'll have the ebook ready for you. I'm still sorting. Then, I'm going to organize the articles into themes or sections. Where the essays overlap, I'll combine or merge multiple articles into one longer original essay. This is an ambitious project, and will take a while. Blogging is currently taking a back seat while I work on the ebook.

Check back for more information about how and when you can get your copy of Coaching Buttons!

Monday, September 12, 2016

Your future roadmap

IT organizations today face constant change. How are you facing that change?

To position yourself for the future, you need to craft a "future roadmap." This roadmap should identify the projects and initiatives that will address known and expected priorities and needs, while providing enough flexibility to accommodate future changes.

Lead an exercise within your teams to identify what your projects and initiatives should be. What is your future roadmap?

In one such exercise, we created this set of ideas, presented here in no particular order:
Advancing Excellence
A plan for substantially increasing IT effectiveness and quality, reducing costs, and boosting innovation.

Change Approval
A formal review board to manage changes to the IT environment via a formal request and approval mechanism.

Business Intelligence
Tools designed to improve how data is gathered, analyzed, and shared across the organization with the goal of fostering a culture of collaboration and data-driven decision-making.

Eliminating the organizational "digital divide" by expanding access to high-speed Internet.

IT Governance
Common business methodologies for work and resource management. Every major work effort should have a governing body that provides direction.

Technology Innovation
Foster partnerships in support of technology innovation to transform the organization.

Increasing high-speed wireless Internet coverage in critical spaces.

IT Service Management
ITSM helps develop and implement key industry standard (such as ITIL) service management processes and supporting tools to manage the IT environment more efficiently and cost effectively, while providing  high quality services to customers.

Data Center Transformation
Consolidate servers and operate data centers more efficiently to reduce costs, free up space, and go green. Also consider outsourcing "commodity" services to the Cloud or vendor-hosted solutions.
Other future opportunities include: Collaborative work environments, "One IT," mobile apps, data analytics, IT rationalization, communication and collaboration, Cloud computing, IT optimization and IT infrastructure.

Do you maintain a future roadmap for your IT organization?
image: chintermeyer/Flickr (cc-by)

Friday, September 9, 2016

Leadership lessons at the Government IT Symposium

I am excited to share that I will be presenting "Leadership lessons from unusual places" at this year's Government IT Symposium, in Saint Paul, Minnesota. I hope to see you there!

The topic comes from a sometimes-repeated topic on this blog: I like to find leadership lessons in unusual places. Often from television or movies, these leadership lessons look at a scenario from a different perspective. You can learn many lessons about leadership from TV shows or movies, even such unlikely sources as Breaking Bad, Superman II, Pulp Fiction, Disney's Mulan, Star Wars, The Walking Dead, and My Little Pony: Friendship is Magic. There's something for everyone!

If you're planning to attend the Symposium, please attend my talk. It will be an engaging audience discussion as we review the lessons together. You'll have a lot of fun—and you'll learn a few leadership takeaways!

My presentation is set for Wednesday, December 7th, 2016 11:30 a.m. to 12:30 p.m.

I'm also doing a second talk about usability, with a presentation titled "Usability testing in open source software." Check out my other blog Open Source Software & Usability for more info!
image: MN Government IT Symposium

Monday, September 5, 2016

Yes, but no

A former colleague from the University of Wisconsin-Madison once showed me how to build trust within teams through the "Yes and" approach. When you say "Yes," you provide agreement. If you build on that and say "Yes and," you lend support.

Practicing "Yes and" can be a very powerful team building exercise. When I experienced this in a workshop, we did it this way: We broke up into small groups (three or four people) and had one person start with a statement. The group (including the first person) took turns saying "Yes and" to build on the statement: "I'm enjoying today's workshop." "Yes, and you can use the lessons in your day-to-day leadership." "Yes, and if you exercise this every day, it becomes a habit." "Yes, and I can do some defensive scheduling on my calendar to reflect on how I'm using it." When the group ran out of "Yes and" responses, we had someone else start again with a new statement.

I prefer "Yes and" statements. They are positive, reinforcing conversation tools that build trust. In contrast, "Yes but" statements erode trust. Some people seem to think it's the same as "Yes and," but it's not. "Yes but" is at best a way to stay on both sides of an issue. At worst, "Yes but" is a negating statement. The "Yes but" statement says "Yes, I agree with you, but not really."

Consider this exchange: "I'd like for us to work on project X." "Yes, but do we have the funds for it?"

The first person might be a manager identifying a new project for her team to work on. Or the first person might be a staff member suggesting a project he would like to be assigned to.

Maybe the second person was agreeing to the project idea, but was genuinely concerned if there was space in the budget to pay for it. Or maybe the second person wasn't interested in the project, and was trying to side-step it. In either case, the "Yes but" immediately presents a road-block to the conversation.

To me, if you say "Yes but," you are really saying "No." It's just a more creative "No," or a softened "No."

How would you turn this "Yes but" into a "Yes and" statement? Try converting the "but" statement into an action statement. "I'd like for us to work on project X." A manager responding to a staff member might say, "Yes, and I'll check the budget to see if we have the funds for it." A staff member answering a manager might reply, "Yes, and I'll do a rough estimate on costs so you can fit it in the budget." Both answers provide support for the idea, and raise awareness of costs and funding.
image: richoz/Flickr (cc-by)

Monday, August 29, 2016

Good and bad bosses

We've all had good and bad bosses. Hopefully, you've had more good bosses than bad bosses. Nothing can sap the energy from you like a boss you don't like. On the bright side, a good boss makes you feel valued and excited to come to work every week.

No matter what bosses you've had, I hope you learn from them. What best practices do you observe that you can adopt for your own management style? What bad habits do you notice that you should avoid?

In this light, I'd like to reflect on several managers I've had over my career, both good and bad. I'll use first names only, for the sake of privacy.

My first job after university was systems administrator for a small geographics company. We made custom maps. I had a great boss! I've mentioned Gwen a few times on this blog; she was an inspiration to me. She helped me through some tough first experiences at work, like the first time I made a mistake on one of our Unix servers. From Gwen, I learned that while it may feel like this the first time anyone has done this (such as when you're facing a mistake, or stuck on a problem) others have probably done something similar before. Don't be an island; don't go it alone. Instead, be a peninsula; attach yourself to someone who has been there before, and get their help.
My next job was at a small company owned by a law firm, scanning and processing legal documents. We helped law firms sort through mountains of paper, an especially valuable service as part of "electronic production and discovery." My boss here was not that great. Jerry seemed supportive, but when the chips were down he only looked after himself. I learned to be careful of him when we went to meetings together. I also learned to watch my back. And along the way, I learned how to read upside-down; Jerry often left planning memos laying on his desk when we met, and these accidental previews were often my only warning to what changes were coming.
I then moved into higher education, leading a web production team at the University of Minnesota. I would stay in higher education for the next seventeen years. My first boss there was Mike. From Mike, I learned the importance of meeting with people, of building coalitions to work together. I also learned that relationships matter, especially with people who don't see eye-to-eye with you. You can leverage the relationship to work past difficulties and get things done.
Technically, Bob wasn't my boss; he was an outside contract project manager we hired to uplift our web registration system. But my real boss, Mike, realized the political importance of the web registration upgrade, so he assigned me and my team to work with Bob and deliver the new system. Bob and I got along pretty well. I didn't take my day-to-day direction from Bob, but we would often meet anyway to plan what was coming up. I learned to always plan for the future, and to always have a plan "B" ready to go. And by watching Bob in difficult meetings, I learned that you should always know who your friends are before you walk into an argument.
Kari took over for Mike after he left the U of M, so I reported to her for several years. Kari was great to work with. She had an innate understanding of the importance of play. We had a chessboard in one corner of the office, and developers and database administrators would sometimes take breaks to challenge each other in chess. I was wary at first, but the opportunity to step away from a problem and to apply their minds in a different way often lead to discovery and new solutions.
After the U of M realigned its technology units, I was moved to the Central Computing Operations, part of the Office of Information Technology. CCO supported the enterprise systems across the U of M. My new boss, Nick, taught me how to on-board new staff, especially as I transitioned to my new role. Nick brought me to meetings and exposed me to executive-level briefings. With Nick, I learned the only way to tackle large projects (we supported PeopleSoft and the registration systems for the U of M) was to have confidence in your team members to do the right thing, and in return the manager needed to be there to support the team members and remove obstacles.
I later moved into a senior manager role within the Office of Information Technology. For a time, I reported directly to the Deputy CIO. Scott was a great manager, and I learned from him that people grow best when you give them responsibilities that are just outside their current capabilities. Watch them, make sure they are supported, but leave them to take on the larger role. Under Scott, I grew quickly. It wasn't uncommon to be in a leadership meeting, discussing some problem that needed fixing, and hear "let's form a working group on this, and Jim can lead it." And somehow I always managed to get the team to pull together and figure it out.
By watching Doug, I learned several lessons about what not to do, how not to act. For example, model the behavior that you want reflected in the organization (Doug modeled poor behavior). But I did learn one or two good things from Doug. For his faults as a leader and manager of people, Doug was a very good project manager. By working with Doug, I learned how to manage projects more effectively, including how to develop and leverage an effort-based workplan.
I moved to the U of M Morris as the campus CIO, and worked under Lowell, one of our vice chancellors. Lowell was a very supportive manager, and an insightful leader. He also delegated well. When we met to discuss issues and plan projects, he always left the technology leadership to me. "Jim, I hired you to lead the IT, this one's yours." Lowell also helped me reach out to the campus, and coached me as I navigated a minefield of campus issues.
I'll call him Butthead so I don't have to use his name. Technically, all the campus CIOs and collegiate IT directors had a dotted-line to Butthead through an organizational alignment. I reported directly to Lowell for day-to-day and most strategic planning at Morris, and had a dotted-line to Butthead for certain strategic items for system campus planning. Butthead liked to play the role of benevolent mentor, but in reality he was petty, childish, immature, and manipulative. But I did learn one lesson: good organizations eventually recognize and reject these bad actors. Technically, he wasn't fired, but the news reported his resignation was accepted "effective immediately," so you can draw your own conclusion there.
After seventeen years in higher education, I moved to local government. I work for a great boss. Johanna provides great coaching. While higher education and government are very similar (we have the same governance, structures, org charts, processes, committees, etc—they're just labelled differently) there are a few differences here and there, and it's good to have someone to help me out when I need it. Johanna was my predecessor in my position, so I can always go to her to ask advice or to seek background context on a situation. But she never gets in my way; she doesn't try to be the CIO. Johanna leaves IT decisions to me, and she takes care of the larger issues for our section of the organization. That makes for a successful partnership.

Monday, August 22, 2016

How to get noticed

While I'm talking about resumes, I wanted to share this brief article at FastCompany: I Hire Engineers At Google—Here's What I Look For (And Why) by Keawe Block. It's an interesting read, especially if you are a student looking for your first job. Block shares these four lessons in job searches:

1. Don't disqualify yourself.
From the article: "Recent experience has taught us that we can find great tech talent in a much wider range of places than previously thought. For one thing, there are far more qualified college applicants than there are spaces for them at top universities. And for another, computer scientists aren't always aware of their talent for coding by the time they’re 18 and have to declare a major." Even if you don't think you're a 100% perfect fit for the position, it's worth applying for anyway. Your different background and unique perspective might land you the job.
2. Show what you can do, even if you didn't learn it in school.
Brock explains, "Yes, engineers need to be able to code. But we're interested in hiring actual people, not machines. So on your resume, instead of listing your GPA (which we no longer use to determine candidacy), give us details about your experience at hackathons, coding competitions, or programming assignments at work. Just because it isn't an academic credential doesn't make it any less relevant. Not only does this create a more textured portrait of your abilities, it’s a great way to prove your engineering chops if you majored in sociology, for instance."
3. Get ready for coding exercises.
If you are applying for a technical job such as a software developer, you should still expect to do the typical coding exercises. These might be on a whiteboard, and usually involve some simple task. It's amazing how much you can learn about a person simply by asking them to write a sample program that sorts a list of numbers, or to write a program that counts 1 to 31 and prints "foo" for every number divisible by three, "bar" for every number divisible by five, "set" for every number divisible by fifteen, and otherwise print the number. These are trivial 1000-level computer science quiz questions, but if you can't answer that in an interview, you won't get a job there.
4. Remember what got you noticed in the first place.
Avoid impostor syndrome. Many of us get this when we first change jobs, which can be crippling during an interview. "Do I really belong here? Am I really qualified?" Yes, you are qualified. You do belong here. From the article: "Some newly hired Googlers experience it when they first step on campus, and sometimes it crops up periodically during their tenures. While this is a completely normal response, it's a counterproductive mind-set while you're gunning for a tech position. I've seen it get the better of candidates and completely derail an interview."
image: FastCompany

Lessons from hiring data

Since I just mentioned Marissa Mayer's resume, it's also worth mentioning another interesting article about resumes. Aline Lerner used to do technical recruiting at TrialPay, and analyzed a few hundred resumes to uncover what works and what doesn't. On her blog, she provides lessons from a year's worth of hiring data.

A few things to note:
  1. Typos and grammatical errors matter more than anything else
  2. Having attended a top computer science school doesn’t matter
  3. Listing side projects on your resume isn’t as advantageous as expected
  4. GPA doesn’t seem to matter
  5. Having worked at a top company matters
The key takeaways include:

Proof-read your resume!
From the article: "The most significant feature by far was the presence of typos, grammatical errors, or syntactic inconsistencies." And: "In startup situations, not only are good written communication skills extremely important (a lot of heavy lifting and decision making happens over email), but I have anecdotally found that being able to write well tends to correlate very strongly with whether a candidate is good at more analytical tasks."
Aptitude matters more than GPA
This is good news if you didn't do well in classes, but you have the skills to do a good job. I'll share that when I hire, I usually only pay attention to GPA if this is your first job. Once you've demonstrated success in at least one other position, your college GPA doesn't hold the same importance.
Format your resume!
It's up to you to make your resume stand out from the crowd. As simple as it seems, formatting means a lot. You need to make your resume easy to read, and easy to skim. Use clear formatting around section headings, such as borders that span the width of the page. And this note from the article about word choice: "As you can see, 'good' resumes focused much more on action words/doing stuff ('manage,' 'ship,' 'team,' 'create,' and so on) versus 'bad' resumes which, in turn, focused much more on details/technologies used/techniques."
Your highest degree doesn't matter that much
Even if you don't have a degree, Lerner's analysis shows your chances are very good. In fact, Lerner found "the higher the degree, the lower the offer rate." Again, it comes down to what you can do.
BS from a top school doesn't matter much, either
From the article: "In a nutshell, when you see someone who doesn’t have a pedigree but looks really smart (has no errors/typos, very clearly explains what they worked on, shows passion, and so forth), do yourself a favor and interview them."
Personal projects may not stand out
The analysis here basically comes down to this: For a while, a lot of hiring managers wanted to see you demonstrate yourself via your side projects, and might examine your GitHub projects. But a lot of people have learned to game this system, and will fork a repository just to make a few minor edits. VoilĂ ! You've got a side project on GitHub. So the good projects tend to get lost in the noise. Unless your side project is particularly noteworthy, hiring managers may not notice.
image: my own (see "On writing resumes")

Marissa Mayer's resume

I'm helping two colleagues with their resumes, so this item stood out to me and I wanted to share.

From the moment Marissa Mayer stepped into the CEO role at Yahoo! in 2012, I was very impressed with her. Mayer was charged with turning around a company that was definitely headed for Internet extinction. The fact that she revived Yahoo! is a testament to her leadership and tenacity.

Among other things, I highly respect Mayer for her data-driven decision-making, especially unpopular decisions like deciding to eliminate telecommuting. The data showed that in-person work was more efficient, as people could gather together for impromptu meetings around a whiteboard to work through a problem. So she opted to eliminate that. I am sure many folks were not happy, but you can't argue with Mayer's results; Yahoo! remained viable for several more years.

As Mayer gets ready to depart Yahoo! to whatever comes next, it's interesting to note her resume, which a colleague had posted via LinkedIn:

When I worked in higher ed, I sometimes advised students on job searches. I would also offer resume and interview coaching to our IT student employees. I wrote about several examples on my blog about what to put in your resume and how to format your resume. Mayer's resume is a great example of a clear, concise resume. Interestingly, it fits on one page—an impressive feat for someone at the CEO leadership level.

A few things to note about her resume:

Use headings to offset content
Mayer's resume is easy to scan. If you were looking just for her work experience and her education, you can quickly find that. This is important to remember if you are a student applying for an entry-level position; most hiring managers will start with your experience and education.
Lead with action
In Mayer's work experience, she uses bullet points to highlight her major achievements in each position. These bullets start with action words: Led, Acquired, Built, Tripled. Anyone scanning her resume can immediately pull out the major achievements at each position.
Highlight things you're proud of
Mayer's resume includes a separate section "Most proud of" where she highlights four accomplishments. As you write your resume, think back on what personal aspects you would carry forward. What makes you stand out?
image: @marissamayer/Twitter

Monday, August 15, 2016

How to lead an affinity exercise

My job is to provide leadership to my IT organization, but often that leadership involves soliciting ideas from a larger group. You might lead a governance group, or you might meet with your entire team as part of an annual meeting. It's good to leverage meeting opportunities to caucus the group and tease out common ideas.

But how you solicit ideas may differ depending on the size of the group. Methods that work well in a small setting (say, ten people) will not work with larger meetings (for example, a hundred people).

For small groups, I often use a SWOT exercise. I usually re-brand this as "Plus/Delta for Now/Future" as a way to get people thinking about what works well and what we should change in the immediate timeframe versus over a longer period of time.

In larger groups, I rely on some variation of an affinity exercise. Here's how I do it:
First, break the room into smaller groups. I find the best group size is five or six people.

Start with a question. At work, I used "What's one or two things we might do differently to make our work easier or better?" Ask the room to use "i-time" ("individual" time) to think about the question and come up with a few ideas. For a large question like my example, I may prompt the question ahead of time and ask people to come to the meeting prepared with a few thoughts.

As they think about the question, each person in each small group should jot down their ideas on slips of paper, like a Post-It note, one idea per slip of paper. I usually limit each person to five slips of paper. They may ask, "What if I have more than five ideas?" I challenge them to be their own filter and come up with their best top five. This avoid one person dominating their small group by "spamming" them with a ton of ideas. At the same time, if you have only three or four ideas, that's okay too.

Give the room ten minutes or so to come up with ideas, then set each group to discuss the ideas. Every person should briefly (!) share each of their ideas with their group, and the group picks the top three ideas. Have each group write their ideas on easel sheets, one idea per easel sheet.

Now repeat the previous exercise with the entire room. Go around the room and have each breakout group present their top three ideas. After you've presented all of the easel sheets, let the room help you arrange the ideas into "themes" or "groups" of related ideas. Often, there is a lot of overlap, and generally the room has pretty good consensus to how the ideas relate to each other.

Congratulations! You have successfully polled a large group to identify priorities or themes! And everyone worked together. Everyone had a voice.

The affinity exercise can take up to an hour, but it's a great way to focus a large group down to a few ideas. At work, my all-team meeting involved eighty-something staff, eleven breakout groups, which generated thirty-three group ideas that we consolidated to eight themes. We have since adopted these eight themes as team priorities.
image: Dean Hochman/Flickr (cc-by)

Monday, August 8, 2016

Seven leadership lessons

I wanted to highlight this op-ed from Randy Johnson (Hennepin County Commissioner). Johnson writes in the July 25 Leadership Edge for the National Association of Counties with seven lessons for aspiring leaders. Johnson is about to retire after 38 years in public service, and he shares these lessons for aspiring leaders:
  1. Decide whether or not to take it on in the first place
  2. Go beyond the talking points
  3. Understand your opponents' arguments
  4. Build coalitions
  5. Never burn bridges
  6. Leadership means different things
  7. Be flexible, and remember rule #1
Johnson's article goes into more depth, but you should recognize several of the above as themes from Coaching Buttons, especially about building relationships. Take a moment to read Johnson's article.

Monday, August 1, 2016

Reflections on leadership

Before joining Ramsey County, I worked at the U of M for 17 years. One thing about higher ed is they value investing in people. Our CIO heard from other national higher ed CIOs that the IT Leaders Program (“ITLP”) from MOR Associates was a very strong program, so he put together a “pilot” group from the U of M to join other schools in an ITLP cohort. I was part of that pilot cohort, joining University of California-Berkeley, University of Washington, and Pennsylvania State University. I went through the program a second time in 2010, part of a development program for senior IT leaders at the U of M.

I had been through several leadership programs in my career, but ITLP was easily the best program I had experienced! Part of what makes ITLP stand out is the level of engagement. ITLP uses small group breakout and other exercises to engage you. By the end of the week, you feel energized but exhausted at the same time. Between sessions, you do coaching with a mentor in the program – and they encourage peer coaching so you can learn from each other. Through coaching, lessons from the program become habits.

The program updates their content every year, but the general outcomes are listed above. The program can be tailored for different levels in the organization, but the cohort I am trying to put together will be aimed at managers and team leads (i.e. not staff who are future leaders).

MOR Associates also hosts an annual leadership conference where you can “recharge” what you learned in ITLP, and bring new lessons back to your organization. Several weeks ago, I participated in this year's leadership event. At the conference, we engaged with other leaders who have been through the program. It was a very leaderful time!

Throughout the event, we also heard reflections on leadership from several CIOs in higher ed. This week, I wanted to share some of those reflections. MOR Associates posted the videos on YouTube, and I have linked to them here for you to watch:

Bruce Maas, University of Wisconsin—Madison:

Len Peters, Yale University:

Sue Workman, Case Western Reserve University:

John Gohsman, WashU:

Steve Fleagle, University of Iowa:

And this bonus video on the essence of leadership, summarized by Gen. Colin Powell:

I'm not affiliated with MOR Associates or ITLP, but I have been through the program and I think it's great. You can learn more at
image: MOR Associates (logo)

YouTube channels:
MOR Leadership
Sean McDonald
jjbpaca (Powell video)

Friday, July 29, 2016

Happy sysadmin day!

July 29, 2016 is System Administrator Appreciation Day! I wanted to share a special shout-out to our system administrators at my office.

Also on a day like today, I'd like to reflect on my background as a systems administrator, long ago. My first job was managing Apollo DomainOS/AEGIS, HPUX, and SunOS servers and workstations for a small geographics company (we made custom maps for businesses). I was fortunate to have a wonderful boss who respected me and took me under her wing. She was my first mentor.

Every sysadmin has a story when they accidentally mis-typed a command or clicked on the wrong control and took down an important system. And after I'd been with the company for about nine months, I did that; I hosed a system with an rm -rf * in the wrong directory. I thought I was in the temporary directory, but I was in a system directory instead. I immediately freaked out! I went to my boss and told her what happened. I'm sure she was disappointed, but instead of yelling at me, she explained that in IT this happens to other people, and now it has happened to me. I wasn't the first to make a mistake like this. There was a way out of it.

She had me take a step back from the console, calm down, then think out loud about what we could do. I couldn't "undelete" the files, but I realized we had other servers exactly like this one. As long as I didn't shut down the system, the server would continue to function. I just had to copy over the files from another system like it, and make a few edits that were local to the system.

Over the next hour, I focused on repairing the system, which stabilized things. By the end of the day, I'd brought the system back to normal, and I was confident enough to reboot the system for a test. And it worked!

That was a scary moment, but I made it through with my boss's support.

I have since moved on to other companies as a system administrator, and never repeated that accident. Whenever I or someone on my team made an oops, I repeated the same thing my first boss told me: this has happened to other people, they fixed it, you can fix it too. I've moved into management and leadership roles, but I will never forget my first boss. As I've managed system administrators in my own teams, I hope I've provided the same support.

Happy system administrators day to you!
image: Christian Cable (cc-by)

Thursday, July 28, 2016

Partnership, Innovation and Excellence

I wanted to share this excellent article by my friend Helen Norris at Chapman University about how IT leaders can achieve top level service and support, at the CIO Talk Network. Go read it now.

In her article, Helen discusses adopting a "Life of P.I.E" approach, summarized here:
"The Life of P.I.E approach is a combination of a business model and lifestyle that revolves around continuous Partnership, Innovation, and Excellence. The three fundamental pillars create a robust foundation that helps bring the [control] framework theory into play and also enables a lifestyle that IT leadership can adopt as they serve their clients, organizations, and team members."
image: CIO Talk Network

Monday, July 25, 2016

Reflections after six months

I have been in my new position for just over six months now, and I love being part of Ramsey County! I am excited to come to work every day! We have made several key changes over the last six months, and we still have a lot of work to do, but we are doing it together. I consider myself fortunate to have a wonderful staff, leadership team, and colleagues at Ramsey County!

At about six months into the new position, now is a good time for reflection. Allow me to share a selection of my responsibilities at Ramsey County:
Direct and manage all aspects of Information Services for Ramsey County. 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.

Selected Responsibilities

• Through an Information Technology Plan, lead the strategic direction for IT and guide all staff in the achievement of this vision for Ramsey County.

• Create and maintain highly professional, customer-oriented, innovative, and future-focused IT capabilities in the department including operations, enterprise applications, information security, and project management office.

• Ensure the provision of secure and stable IT services in a cost effective manner to support business outcomes through effective risk management strategies.

• Ensure physical and logical security of all County computing assets, including data.

• Direct the development of and promotion of policies and standards covering County-wide IT related functions including procurement, technical infrastructure, information security, records management, and projects.

• Manage the development of IT annual budgets and monitor performance against established budgets and plans; communicate on behalf of IT to state auditors.

• Continuously and proactively seek ways for IT to deliver value to the County, including identification of new sourcing opportunities. Help the County realize new IT enabled business opportunities.

• Direct IT governance for the County. Serve on County-wide committees including the County Manager's Senior Management Team, and chair the County's Technology Governance Committee. Participate in planning and policy making at the executive level.

• Direct and perform special studies for the County to identify areas of potential improvements in IT and across the County's IT delivery structure.

• Maintain liaison with other public and private organizations.
Colleagues from my time at the U of M have asked me "What's it like in government?" I find it is very much the same. We have the same processes, the same structures, the same governance, the same committees, the same org chart … it's just labelled differently!
image: Ramsey County website

Monday, July 18, 2016

I'm thinking about writing an ebook

I am thinking about writing several ebooks. The ebooks will span a range of topics from leadership to usability to open source software. Several will be based on my blogs, others will be contributed chapter compilations in collaboration with different authors.

At the moment, I'm thinking the ebooks will be made available for free, also available on the Amazon Kindle bookstore, and probably Apple iTunes Bookstore and Google Play Bookstore. Distributed under a Creative Commons Attribution license, contributors can submit a previous work or write something new. Authors retain the copyright to what they submit, and can re-use their contribution elsewhere.

These are the ebooks I am considering:

Open Source Usability
Open Source Usability
An ebook about how to examine and improve the usability in free and open source software. While many books exist about usability, none specifically focus on free and open source software. Intended for developers, this ebook will discuss what usability is, different ways to examine usability, how to measure usability, and ways to integrate usability test results back into the development stream to improve the next versions of the software. See my blog: Open Source Software & Usability.
Coaching Buttons
Coaching Buttons
An ebook comprised of about fifteen chapters from my Coaching Buttons blog, about Leadership and Vision in Information Technology. Organized into several themes of leadership, this ebook will be interesting to current and aspiring leaders.
Why FreeDOS
Why FreeDOS
An ebook about the FreeDOS Project, how it got here, and who contributes to it. Comprised of about fifteen contributed chapters, organized chronologically by date of first contribution, this ebook will be interesting to open source developers and others who want to get involved in free and open source software.
Focused Leadership
Focused Leadership
An ebook aimed at emerging and rising technology leaders. About fifteen chapters written by contributors at various levels of leadership, from team leads to CIOs and CEOs, in higher ed, government and industry. Chapters will be organized into three sections with about five chapters each to discuss roles that are primarily Lead, Lead+Manage, and Lead+Do.

I'm not sure what the audience would be for these ebooks. What do you think? Would you read these ebooks? Let me know in the comments, or send me an email.

Monday, July 11, 2016

Career ladders

A few years ago, I served on a committee to identify new career ladders for our IT teams. This work originated with a document I wrote about how to "level set" the compensation and seniority for our operations and infrastructure staff, many of who had joined our team as part of IT consolidations from different parts of the organization. In that document, I set a new career progression, from "junior" to "staff" to "senior" to "team lead," with compensation ranges for each. This document was going to be the basis for a re-organization of my teams.

My director liked the idea of planning for career levels, and we moved the idea forward to our HR department. From that concept, the career ladders committee was formed. The career ladder committee expanded on my original plan, and established a new organizational structure for IT staff, in different categories.

I have since used this career ladder concept as a basis for organizational planning. The document provides a simple overview of technology teams and how job areas are aligned and related. Our work was expansive. We defined eight separate career tracks, with different levels within each:
  1. Development
  2. Database Management
  3. IT Security
  4. Systems Analysis & Administration
  5. Network Analysis & Administration
  6. Business/System Analysis
  7. IT Management
  8. IT Generalist

The picture below represents the organizational structure based on that list. The picture should be read from the bottom up, representing the infrastructure, to systems, to development, to support of the end user. The usefulness of this picture is to ensure that our career ladders do not miss any key areas or functions of IT work, requiring significantly different skill sets, work knowledge, and responsibilities; specifically, a different career path.

Enduser/desktop/helpdesk supportManagement
Code Migration
Change Control
Software Admin
Application Support
Systems DBAApplication DBA
Systems AdminSecurity
NetworkData CenterOperationsAutomation

How do you manage career ladders at your organization? Do your staff know how they can advance? Every organization has "star" performers who excel at what they do, and who want to do more. How do you reward these employees? How does your organization invest in them?

It's often said that the best reward for hard work is more work. And that is true to a point, and gets you pretty far with many people. But you will eventually need to consider career progression for these top performers. How you engage them in their careers goes a long way to retaining your top talent.