Getting promoted into a CIO role is exciting... until you need to start managing people! Benny Sisko provides you with six tips for being successful with your new staff.
For the new CIO, assuming responsibility for a staff can sometimes seem like a daunting challenge, especially if you've come up through the IT ranks. While there are certainly many ways to screw it up, there are also many ways to succeed. Here are six tips gleaned from my own sometimes painfully acquired experience.
Establish a vision
No matter how long you've been a CIO, your team has to know that you have big things - or at least a direction - in mind. No one wants to work toward unclear goals that may or may not line up with the overall organizational strategy. Make sure that you continually communicate a vision to your staff and make sure that they have enough knowledge and information to be able to take part in informing that vision.
Get the right people on the team
Only lazy employees want other lazy employees around and employees with bad attitudes can destroy a team. Perhaps the hardest decisions that have to be made are those revolving around the people side of the organization. After all, if a router goes bad, you don't mind chucking it out the door, but even the most negative or the laziest employee still needs a livelihood and it's far from easy to make the ultimate decision regarding the fate of another person.
That said, there comes a point when you can't put it off anymore. If you have a boat anchor on your staff that's bringing down the entire team and you've exhausted your other options, it's time to end the employer/employee relationship and bring someone in that can do the job and with a good attitude. I've gone through this process and it's painful, but almost two years after I fired one-quarter of my staff, I now have a team on the ground that I trust. Our customer feedback ratings are through the roof, overall productivity is higher and no one on the staff feels like they're pulling more weight than someone else. I'm constantly stopped in the hallway to be told about the "service with a smile" that our staff gets from the new people. The lesson: In the short run, letting people go is a gut-wrenching activity, but it's sometime the right thing to do.
Delegate... or at least try to
Right or wrong, my level of delegating is directly proportional to my faith in my staff. At the end of the day, I'm the one on the hook for making sure that IT's priorities are met so if I don't trust, it's hard to let go. With a robust, trustworthy staff it's been much easier to delegate in a way that makes sense for both me and the staff. For those CIOs that have risen through the ranks, this is probably one of the most difficult behaviors to learn. We're taught to be hands-on problem solvers and all of a sudden, we're supposed to be expecting <gasp> other people to do it for us! Here's the ugly truth: If you don't learn to delegate, one of two things will happen: 1) Your staff will quit; 2) You will be in the unemployment line.
Involve others in key discussions
As the CIO, it's really easy to get stuck in a rut of attending the high level meetings yourself. Of course, you should attend these meetings, but don't hog the glory. In my organization, my number two attends executive meetings when I'm away and, on occasion, joins me even when I'm attending. Our organization is also in the midst of a strategic planning dialog. I've invited another manager on my team - below my number two - to take part in these discussions with me. My goal is to broaden his horizons beyond his day-to-day world and the effort is definitely paying off. In the past year, he's clearly begun to have a better understanding of the "why" behind my actions in ways that I could never explain in words.
Clearly define priorities. This goes along with defining a vision, but whereas defining a vision is a sort of up-front activity, priority definition is an ongoing effort and can be harder than it sounds. Remember, what you say to someone is only half of the story. What they hear is the other half and can be wildly different. When you assign a project or task, make sure the receiver understands its priority against other tasks and the full scope. Obviously, over time, you'll learn to read each other better and might not have to be quite as detailed, but make sure you both understand your communication limits before you start making assumptions.
I schedule my staff meeting for immediately after executive staff meetings. During my staff meetings, I share as much as possible with my staff. Obviously, I don't go into sensitive personnel issues or other items that could be problematic. However, my staff knew immediately from me that we wouldn't be getting raises this year and why. Some people in other departments didn't know until an email went out a couple of weeks later. I can tell you that my staff reacted very, very well to the bad news. No one was mad or angry with the company. I asked them why they weren't mad and they told me that I'd been keeping them well-apprised of our budget difficulties so they weren't surprised in the least by the salary news. I operate on the principle that I never want my boss to be surprised... on the flip side, I don't want my staff to be unpleasantly surprised, either.
Listen and don't be afraid to back down
This one is the most important point, so I've saved it for last. When it comes to your job, listen twice as much as you talk. When it comes to staff, listen to their concerns and listen to their sometimes vehement pushback. If they're right, give in. If they're wrong, don't. I've been on both sides of this before. In a previous position, I had two members of my staff in my office arguing that they could not possibly complete the project list that I had put before them in the time frame I specified. Not once did they provide me with good reasons beyond "we can't do it" so I stood my ground. In my current position, I had a staff member raise concerns about an upgrade schedule I had proposed. She came to me with a bulleted list of items that would be affected and reasons why waiting a month made more sense. She was right so I backed down and we changed the schedule. In both cases, the end result was fantastic. In "project list" example I listed, on my last day, one of the people that had been pushing back thanked me for pushing them to new heights both in their skill levels and in the way that they were perceived by the organization.
I'm definitely not claiming to be some sort of superhuman here; for every success story, there are many more "teachable moments" that have probably helped me to learn more than all of the successes combined. But, when it comes to managing my staff, these are six items that have served me well.