IT leaders must be prepared to have difficult conversations with their bosses, with their customers, with their teams and with themselves.
By Charles Araujo
Over the last month, a single word has repeatedly risen in my consciousness. I started the month delivering the opening keynote at the LEADit conference in Canberra, Australia. I returned home and immediately left for the Pink Elephant Leadership Forum in Scottsdale, Ariz., where I delivered a morning keynote. As I spoke and then talked with people afterward, I found myself repeating the same word again and again: courage.
While in Australia, I also participated in a "hypothetical." Originating in the U.K., a hypothetical is a simple panel construct, but one in which the participants play a fictional role in a hypothetical situation put forward by the session moderator; in our case, the moderator was the indefatigable Rob England, better known as the IT Skeptic. During the hypothetical, I played the role of CIO and, because of the challenging hypothetical situation, I kept having some difficult conversations with the rest of the panel. As we wrapped it up, I said, "The issue we haven’t addressed is there is a good chance that if I acted like this in a real career environment, I'd be looking for a job soon. These are tough conversations to have. They take a lot of courage. But the best, most successful IT leaders I know are having these conversations every day."
The incident made me realize that "courage" is the one thing that we don't discuss enough when it comes to what it takes to be a great IT leader—the kind of leader we need to take us into the future. But as I contemplated it further, I realized there are four specific, courageous conversations that every IT leader must be prepared to have if you are going to lead your organization into the future.
Conversation #1: With Your Boss
“What are we capable of accomplishing?”
One of the consistent themes during the hypothetical was the balance needed between IT's current commitments and new projects in the pipeline. Rob England deftly played the "minister" (we were a government ministry in the hypothetical) and kept putting ever-new demands on the organization, driven by the political crisis of the moment. I found myself constantly saying, "If this is your new top priority, then we will need to discuss what things we are not going to be able to accomplish so that we can get this done." It was a constant struggle of prioritization. True to form, England pushed back, saying that he needed it all done, which forced me to stand my ground and insist that he prioritize the demands or put our entire delivery model at risk.
Telling your boss "no" is never easy and will often put you on the fast track to a new position "outside the organization." Therefore, many IT leaders understandably never go there. They put up a mild protest, but then take on the new responsibility and do their best to manage. This is why most IT executives (and their teams) are under such strain. We have rampant demand that far exceeds supply. IT leaders may be reticent to say "no," but, clearly, saying "yes" unconditionally isn't the answer either. Instead, a more courageous conversation is required.
I believe the right response in this all-too-common situation is, "Yes, we will need..." The key is to not refute or deny the new demand, but simply state to the requestor what it will take to deliver it. This is fundamentally a question of capabilities. Every system has a finite production capability based upon design and capacity. In no case, can any system either produce something that it is not designed to produce nor produce in excess of its available capacity. It is a simple fact, but one that we often ignore during these exchanges with our boss. We believe that somehow "we can get it done" and so pretend that we have the capability of accepting unlimited demand. But the hard reality is that our capacity is, in fact, a constraint, and without this kind of control, we will run the risk of delivering only a small percentage of what we have committed to accomplish.
This article was originally published on 09-05-2013