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.

Monday, January 2, 2017

Feedback from Symposium

In December, I was proud to be part of the Minnesota Government IT Symposium, in Saint Paul, Minnesota. I served on the planning committee, led an all-day workshop, and gave three presentations during the conference. It was a lot of fun, and I met a lot of interesting people and attended some excellent presentations.

As a presenter, we always ask for feedback. This helps the conference understand how each session went, and assists in planning next year's conference.

Feedback is also helpful to the presenter. Feedback is a gift, and we should seek out feedback so we can improve ourselves. So I was excited recently to receive my presenter feedback from the Government IT Symposium. I wanted to share them here, with some notes for how I'll use this feedback.
Business Continuity and Disaster Recovery Planning Tech Jam (report-out)
In this session, I provided a recap of the all-day "Tech Jam" workshop on business continuity and disaster recovery planning. I shared what we learned, including the detailed results of the four work groups during the workshop.

No comments.
Leadership Lessons from Unusual Places
This is one of my favorite presentations, and I've given variations of it at different conferences and events. 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).

  • "Maybe for the Star Wars example, use actual examples like you did for the other ones, not just 'what could we tell Darth Vader in a leadership transition.' Because that doesn't really happen in the movie. Your Breaking Bad one was good because you used real examples from the show."
  • "Good speaker. Very entertaining."
  • "So useful and topical!"
  • "By far the best session and most interesting speaker I have seen so far. This was a great session that provided great ideas and knowledge."
  • "Love the presentation ~ very creative way of presenting your information! Don't think I will look at those movies in the same way again!"
  • "I was really impressed at the awareness of your ability to take movies/ tv shows and pull out the leadership skills. Made me aware of the fact that it is not just entertainment!!! I will probably analyze and look at movies/ tv a little different in the future!"
Usability Testing in Open Source Software
In this presentation, I spoke about our usability tests this summer with GNOME and Outreachy. Attendees had great comments about Renata's traditional usability test and Ciarrai's paper prototype test. People also liked the heat map method to examine usability test results. When I talked about the UX test, attendees thought the emojis were a good start, but also suggested the method could be improved. I asked for help to make this better next time.

  • "Very informative and entertaining."
  • "Great presenter and great information."
  • "Interesting, would like to see more examples of results and test questions."
  • "He's open to ideas and feedback from audience."

I appreciate hearing these comments and feedback because it helps me to do better next time. The Leadership Lessons talk was a lot of fun, but I think it is time to retire the "Star Wars" example. I led with that in my presentation because it was the first "leadership lesson from unusual places" I ever did. But it uses a different format and structure than the other Leadership Lessons examples. One reviewer certainly noted the difference. And I agree that the other Leadership Lessons examples are more effective because we are drawing out lessons from something, where in the "Star Wars" example I ask the audience to make recommendations to Darth Vader and Luke Skywalker. I agree that this method is less effective.

I'm glad that folks found the disaster recovery and business continuity session valuable. We worked very hard on this one to create a presentation based on the previous day's workshop. The goal in the conference presentation was to share what we had learned. I also wanted to recognize the effort everyone put in, and let managers know that their staffs' time was wisely used and generated valuable results. We also provided the results to conference attendees for them to use in their organizations and boost their own disaster recovery planning.

Thank you for your wonderful feedback.

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.