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")