How IT Can Say No

Within the IT world, we are inclined to say yes to everything we can, and to take on more and more projects, until we have too many things to do and no realistic way to get them done.

The model of IT as a champion is a good model, because IT should support and enable goals big and small, and act as an enabler for positive change. But saying yes to everything isn’t sustainable - it can lead to employee burnout, a decrease in quality for the work you are able to do, and analysis paralysis when trying to figure out how to prioritize everything.

Let’s discuss some strategies for saying no while still maintaining the feeling of being an IT champion:

One Thing In, One Thing Out

A consideration for taking on responsibilities is to think of your capacity as a fixed number. If you can do “ten things” as a team and there is an interest in adding something new, it can be helpful to reframe the conversation as “What should we stop doing in order to support this?”

This discussion can be scary. All of the work that we do usually feels important, and we want to support everything we can, but we also can usually think of a few things our team supports or does that feel dated or unnecessary. To support the newest cloud webmail client, perhaps we can get backing to drop support for that command-line interface mail client that is only accessible through a Unix terminal. By removing one item from our plates, we now have capacity for the new one.

Getting buy-in for this type of change may require a cultural shift among leaders. To get them there, it is important to start framing things from a capacity management standpoint. One way to help shift is to start treating your own resources, in conversation, similar to how we treat budgets and finance. In those instances, we tend to see those numbers as firm. The budget is the budget and we can’t go too far over it. Getting to this mindset may require budgeting our services and figuring out how much time we spend doing certain things

Saying Not Right Now

“No” doesn’t need to be the end of the road. A key strategy for saying no is to turn a hard no into a “not right now”.

One way to implement this is to start keeping a project request backlog in which you can incorporate agile concepts of prioritizing, and ordering a list of all proposed and future work to help figure out what you can do right now, and what you’d like to be able to do someday. This can be a better way to say no, as it maintains the relationship, and gives someone something tangible to track.

A backlog, especially one you can share with leadership and stakeholders, allows for an informed conversation with transparency and communication. Rather than focusing entirely on capacity, you can start to let leadership choose which work is most important to them based on impact, timing, and resources. You also can show the end users and stakeholders a roadmap of what is in the works. The latter can be especially helpful, as it then becomes a negotiation. Project A may be high priority for us, but the users can see Project Z is next; they can plan better and see where this fits in the overall order of things.

Finding the Right Fit

With IT work, we want to think “No, but…”. Sometimes the easiest way for us to say no is to help others find a yes elsewhere. With enterprise service management, and shift left changing where enterprise-wide work takes place, it can be too easy to add work that may make more sense elsewhere within the organization. This can mean that another team or group has an existing tool or solution, or that it is a service they already provide.

There are benefits to having everything in one tool, but sometimes another team may have a tool that meets the needs of a new request. The tricky part of this is you don’t know what you don’t know, and in a more siloed organization you may not have a full picture of which tools and resources are available, and which services other groups offer.

But keeping open communications between teams can help with this. Ideally this type of work and decision making can happen early on through strong requirements gathering, and some sort of formalized project onboarding or architecture review process.

It can be difficult to give up work that you are excited about or that you know you can complete, but sometimes another tool could work, or another team may have more capacity. Shifting your own mentality from seeing this as a “failure” to help the user into working together as one team can help make this easier.

When we think about the role of IT we want to continue to support the ever-changing environments that we work within, but we also need to know when to say no. Strategies like these can be valuable tools for managing this conflict. Ultimately, we need to remember that saying no isn’t malicious; it isn’t something we should be afraid of doing, and we need to help manage expectations and workloads. One more thing quickly becomes many more things, and it is up to us to try and maintain some work-life balance by saying “no”.