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)