Quick Tips to Improve Your IT Team's Mental Health
Time to Reevaluate the Processes and Who Goes Around Them
At almost every company I've worked for, there is an employee survey sent out annually. Sometimes the results are great, sometimes they're not.
One of the biggest concerns I've heard from IT over the last 10+ years is that IT employees are burnt out. They often feel like they aren't allowed to say "no", or push back against unrealistic deadlines and expectations.
It's the kind of feeling that no matter how much of a bonus or salary you throw at them, it doesn't make up for the stress they endure every day.
If "burnt out" is the type of feedback you're receiving from your team, then it's time to reevaluate the process and say "no" to anyone circumventing the process.
Here are my top 5 tips on how to protect your teams and still achieve what's most important for the company:
1. Empower Your PMs/Managers
IT should be a true business partner. Bringing us into the initial discussions can help the business get the best results and have alternate solutions that just might be better and more cost efficient.
Empower your PMs/Managers to say no to any project starting without it being vetted and estimated by the dev team (more below). You can’t ensure that the team is focusing on what’s most important, nor tracking resources, if requests are slipping by.
Encourage stakeholders/business partners to bring IT on board from the beginning of any business goal, and not as the last resort.
2. Make Your Intake Process Be the First Gatekeeper
Your project intake process should have key questions that make it clear how the request aligns to the overall corporate goals, how it reduces risks, and what type of opportunities it will create.
If you receive a request that lacks this information, don’t let it proceed to prioritization and definitely not to development. Your team is paid to develop and is under a lot of pressure to meet deadlines and provide quality work. Do you really want your team spending time and money on projects that aren’t really important?
3. If Your Dev Team Can’t Do a Safe High-Level Estimate, You Need More Requirements
I’ve witnessed a lot of managers and stakeholders claiming that whatever request is “easy” or “quick”, often providing development estimates that are random guesses and far from reality.
The thing is… No one should be providing a dev estimate except the dev teams.
High level requirements should be gathered enough that the actual IT team(s) working on the project can give a safe estimate of development time.
Then stick to the requirements or make it clear that deadlines can’t be met when requirements change.
4. Prioritize with Actual Team Bandwidth as the Limit to Acceptance
Prioritizations should be executed based on the actual bandwidth that the team has coming up. The bandwidth should account for existing in-flight projects, upcoming needs (like Month End Close support or annual audits), and PTO/vacation.
It should also include a buffer for sudden illness and unforeseen development issues.
Only prioritize up to 50% of your team’s bandwidth, allowing space for bug fixes, production support, and tech debt (maintenance for your system/app, like an oil change for your car). (This only applies if your dev team is also the one doing maintenance, bug fixes, and support.)
5. Put a Stop to Stakeholders Going Directly to Your Team
No stakeholders should be going straight to the dev team with any new requests no matter how big or small.
I’ve met a lot of wonderful developers who simply feel like they can’t say no. They allow stakeholders to reach out to them in private, and begin working on projects that were never vetted and consume time for top priority items.
Stakeholders should only be going through the manager who can evaluate the request and the existing bandwidth and project load. If there is a new crucial request that comes in, then the manager can discuss with all stakeholders which project needs to be put on hold.
It’s Going to Be a Slow Change
Start implementing these, and you'll start improving not only the mental health of your teams, but also the quality of the truly most important projects for your company.
Is it going to cause a rift at the office, with some stakeholders (maybe even ones higher up the chain) complaining that their stuff isn’t getting done just because they want it done?
If so, that’s ok. It’s your job as a leader at your company to make sure that only the most important goals are actually getting done, and not just because someone is screaming.
If it’s going to cost more to build whatever is getting done than the actual opportunity it’s creating, then it probably shouldn’t be done (unless it’s related to legal compliance).
Changing your processes will change the way that stakeholders and leadership look at their requests.
Is it really all that important to change the look and feel of the internal site?
Is it really necessary to create an automation to save 1 person 4 hours per month?
It is really crucial to implement a new tool just because some VP says it’s the next best thing since sliced bread?
Or are the requests coming through really going to make a positive impact on your corporate initiatives?
Remember, every beneficial change causes slowdown in the beginning, but once you keep it going for a few months, you’ll start to see a positive shift in the quality and impact of the work being done.
Don’t give up! This is for the mental health of your team and the financial/impact health of your company.
If you have a lack of true priorities, too much to do and too little done, a budget thrown out the window, and your people are burnt out, then this guide is for you.
In it, we'll dig into:
5 common myths and mistakes and what you should do instead
Quick steps to get you implemented in 90 days
Discussion points for every area of your business, inside and out
You can also set up a 30-minute call for a quick discussion on your situation and how to start getting unstuck.
Ready to improve your resiliency?
If you want to go deeper with me, then subscribe to my Substack to receive the more specific training via email! I’ll be posting insights, exercises, and more on Substack in upcoming weeks!