I recently emerged from an eight-month stint as an interim CIO. I knew from the outset that my position would be short-lived, which gave me the freedom to be more introspective and experimental than I otherwise would. The golden rule that I took from this experience is this: In a typical medium-to-large organization, a CIO’s job is not about technology. It’s about enabling your team to work effectively, and setting the right expectations among your peers and superiors. In greater detail:
Keep your hands off the bug tracker. You’re a manager now, and your job is not to create things. The experts on your team know this stuff better than you do. Your job is to help your team by giving them the space to create things on their own, without you butting in.
This was hard for me: I’m a product person, and I loved taking a peek at our code repositories and commenting on work as it came together. But my words had more weight than I thought. A stray comment from my mouth sometimes took on a life of its own. Simply saying “It would be cool if there were a video on every page” can upend weeks of research that suggest there should be no video. So be careful about injecting commentary on tactical matters best left to the experts.
Be yourself. Don’t fake technical expertise. Technical people are very good at spotting phoniness, and they hate it. They have far more respect for competent managers who confess to not knowing the technology, than for insecure managers who act like they know more than the lead engineer.
I’m very comfortable in the application layer; if a developer had a bug, it was easy for me to make myself useful to them (hence my problems avoiding the bug tracker). But the other layers were somewhat new to me. My infrastructure, security, and support engineers all knew far more than I did. Not only could I not offer advice for solving technical problems; I couldn’t even speak smartly about them. It was very hard to tell the team, “I don’t get it”–after all, if I didn’t get it, why was I in this job? Then I remembered that my job was not to create; it was to enable the team to create. So instead of probing deeply into technical problems, I learned to instead say, “This sounds pretty complicated. Where do you need my help?” They always knew how to answer that question in a way that let me do my actual job.
Expose your peers to the whole house. Your job as the CIO is to maintain the entire enterprise–to support each mission with systems that do not interfere with one another. But many of your peers do not understand the interconnectedness of seemingly unrelated systems, and do not appreciate that supporting one mission with new capabilities could put other missions at risk. This doesn’t mean you give everyone Microsoft Office and call it a day, but it does mean you have to constantly measure the reward of new systems against the risks they bring. Without this context, your peers will see your refusal to provide new capabilities as a failure to support them rather than as a prudent decision for the organization. I believe that a CIO’s shelf life is tied to how well they break their peers of this notion: they need to see the organization’s IT as a shared resource that everyone relies on, instead of a series of independent systems.
I’m unsure how well I did this. But I think I created a useful narrative frame for explaining the problem to non-technical people: I told them that enterprise IT is like a house. People think of their house as a set of rooms that fulfill different functions: the kitchen, the living room, the bathroom, and so on. But underneath these separate rooms, there are critical systems running throughout the house that tie all of these rooms together: wiring, plumbing, the foundation, HVAC, and so on. This means that if you want to add on to your house–maybe you want a bigger master bathroom and a new marble shower with three showerheads–you can’t simply buy the room at Home Depot and shove it up against the side of your house. You have to integrate the new room into your house’s systems in order to provide it with water and power. Once you integrate, you have a new problem: your new room is now impacting other rooms in the house. Your awesome new shower now leeches all of the hot water from the other bathrooms every morning, making your housemates unhappy, and your heating bill goes up, meaning you may have to spend less in other areas.
IT is the same way. Vendors market themselves as the Home Depot of technology, with plug-and-play products that can revolutionize your mission with a one-click installer. It isn’t that simple. On-premise products will share network capacity, compute power, and storage capacity with all of your other systems. Cloud-based services alleviate some of these problems but still have big implications for training, security, compliance, and data integration. When peers approached me with marketing materials they had been given by a vendor, I reminded them about the house: if rushed into, these new products could hurt their colleagues. I found that this message resonates with most professionals: they do not want their success to come at the expense of the greater organization’s. It was doubly important that I gave this narrative to the Bureau’s senior executives. It gave them an easy way to distill complex problems and showed them that my team’s failure to deliver certain solutions was often in the best interest of the organization.
Schedule time to focus on the big picture… Andrew Carnegie once challenged a management consultant named Frederick Taylor to give him one piece of useful business advice. In exchange, Carnegie promised $10,000. Taylor’s advice: Write down the 10 most important things you can do for your business, and start with #1 tomorrow. A week later, Taylor’s check arrived.
Carnegie probably found this useful because it made him realize how much time he spent putting out small fires instead of the things that really matter. CIOs face the same challenge. Systems require constant care and feeding, and every day seems to deliver a new mini-crisis, which distract you from any big visions you had upon your arrival. The only way I could avoid this was to create appointments on my calendar explicitly for thinking about larger problems. Some of these were meetings; some of it was time for me to think to myself. The important part was that it was on my calendar, so it held me accountable and kept others from scheduling over that time.
…and the home front. Because so much of your time is spent with other executives, your team can come to feel distanced from you. I was naïve about how my team perceived me and took a simple approach to keeping an open line of communication with them: I emailed my calendar to all 200 members, explaining that I carve out an hour for lunch every day. “Feel free to pick a day if you’d ever like to chat.” Only one person accepted this offer.
I learned too late in my tenure that it takes more than an open door to stay connected with your team. Talking to the boss may have backfired on some people earlier in their careers, and now they are reticent to do so. And just like you, they’ve got work to do. If they would rather polish their code than have lunch with you, that’s probably a good thing. Whatever the reason, I consistently noticed that the social distance between me and my team was a matter of vantage point: from my perspective, I had a collegial, back-slapping relationship with everyone on the team; I could tell them anything, and I expected the same from them. But from their point of view, I was seldom seen and had zero rapport with them.
So instead of putting the onus on my team to talk to me, I should have more frequently engaged them in their own space (carefully toeing the line between socializing with them and distracting them from their work). As with the previous lesson, sometimes these casual interactions had to be scheduled to avoid falling prey to phone calls and meetings. Failing to proactively engage my team more frequently may be my biggest regret from my term. It was an extremely valuable lesson that I’ll take with me everywhere.