I used to tell my staff, “My ‘yes’ comes easily; my ‘no’ is firm.”
Not everyone believed me.
What I learned early, and taught my teams often, is the core of what follows in this article. But enough about me for now.
You, too, get to say yes and no. No can be challenging.
You do not often say no to things that are trivial; you are asked because your help is needed and their need feels urgent. If not you, who?
This is all exacerbated in our current economy where departments are being asked to do more with less. IT is not exempt.
How do you do more with less? By doing less that produces more.
That is why you must challenge requests. There is only so much you can do, and you must do much with what you do.
“It’s Not You, It’s Them”
Ideally, you are in a company that does a great job of establishing what is mission critical for the next 12-18 months.
If not, then you take the lead in working with lines of business on helping them forecast and determine what goals are mission critical for them.
You are establishing an authority that is not you. It’s the mission criticals, the them.
This is what I worked hard on with my own teams. We were crystal clear on what we were seeking to accomplish and why and how.
The first basis of saying yes or no was to measure requests against initiatives and projects in place that fulfill mission critical.
“But Wait, There’s More”
Once you have tied initiatives and projects to what is critical, you have two more buckets in which they can be placed.
The second bucket is what I call Accomplices. These are projects that do not directly support a mission critical, but they do relate to a critical initiative. Their fulfillment, or lack thereof, will help or hinder a critical initiative.
For example, if a mission critical initiative is to upgrade your Cybersecurity Infrastructure, you may have several other initiatives and projects that support it - MFA implementation, Endpoint Protection Enhancement, Data Encryption. Those are accomplices.
I call the third bucket Accessories. They are approved initiatives and projects that are not tied to the mission critical. I organize those by speed of accomplishment. The faster they can get done, the better.
Requests Are Opportunities People Didn’t See Coming
Requests are routed into two avenues. The first is the avenue of Expectation. It’s communicating the resources and process required to accomplish the task and the timeframe in which it can be done.
The second avenue is Education, which is my favorite, because every request has a context in which it fits: Critical, Accomplice, or Accessory. Also known as the need to have vs the nice to have.
We challenge requests by educating, and we entertain requests by being educated: “This is what leaders have established as critical, and here are all the projects being worked on that support the primary goal. How does your request fit into supporting the primary goal?”
We might learn something.
More often, others learn something. Which will lead to the question, “Then what do I do about X if you can’t do it?” And that’s a different article.
When it comes to challenging requests, you want to establish an authority outside yourself, build context for the work you are doing, and evaluate the ask on the basis of what is essential, supportive, or not related.
I love saying yes. And I don’t like my no being treated as a maybe. The difference is in context - if people see what they want in light of why they can’t have it, they support my answer rather than try to manipulate it.
I had recent conversations with CIOs who talked about the initiatives and projects they have in front of them and asked them the simple question: Have you tied them to mission criticals? They had not.
When that is true, everything else is a competition for your time.
People need to know that is not a contest that can be won. Requests that are granted are always about the fit not the fight.
