You won’t be shocked to hear that many IT people are unhappy. There’s so many reasons this could be the case – they don’t enjoy the work they do, the environment they work in, they have to deal with people they’d rather not deal with, there’s too much expected of themselves (either from them or someone else), they work too many hours…. You’re probably thinking of another several I haven’t mentioned.
It’s also not a singular black or white state, being unhappy. There might be aspects you are happy with, and others you aren’t. I don’t have all the answers to make you happy, but I’ve made a list (and will update as I remember more points, as many I naturally do) on points of consideration that for me personally, have helped. If nothing else, I hope this makes you think about what you do and why you do it which leads to improvements.
This could possibly be better to describe this as contentedness rather than happiness, as a lot of this should reduce unhappy situations. That may or may not leave you with happiness as a result. Talk to peers, friends, family, bosses, HR – anyone, if you’re unhappy. Sometimes just saying it out loud can help. I am not a mental health specialist or qualified in any way, so please do your own research and speak to professionals!
Also, as my background and experience is more on the operational side of IT, there’ll be a slant towards that – but with DevOps and all that, isn’t everyone Ops somehow? :)
At the first time of posting, I’ve made a list of 24 (ok, 27). I expect this to grow – feel free to add your own as a comment too!
With all that out the way, here’s my growing list of ‘secrets’ to IT Happiness:
1. Discuss and question, but don’t argue.
Arguing means you’re talking over someone, and probably in a less than perfect manner. If you’re at the stage of arguing, it’s unlikely you’re going to change the other parties’ opinion. If someone isn’t listening to your reasoning, then look to understand their view and work backwards from that. Arguing will waste everyone’s time, and you won’t walk away happy. Arguing on the internet is a complete waste of time :) However, you should still engage in healthy discussions and differences of opinion – often you’re trying to achieve similar results with different methods, and hopefully some acceptable common ground can be found.
2. Use every challenge (almost) as a chance to learn.
This is a way of approaching problems that you don’t already know how to fix. It doesn’t necessarily have to be technical either; people challenges can be even more draining, but it gives you more methods of how to work with people and get to a resolution you’re happy with. A technical problem you’re stuck on means you probably have already learnt and refreshed some things to get stuck; they just weren’t the things you needed this time.
3. Don’t be afraid to ask for help, and say “I don’t know”.
… but, say you’ll also find out. You can’t know everything about everything and having that expectation of yourself is setting yourself up for disappointment. Finding out who to speak to on a problem, internally or externally is still valuable. You can use that opportunity to learn something too.
4. Never trust the user.
This is what I call ‘Rule 101’ of the helpdesk. Just because someone says something happened doesn’t mean it’s true. It might be true, or it might be very close to true… but it also might be completely wrong. Going down rabbit holes when a few clarification questions at the start of a conversation could save you hours of fruitless work. Prove the problem before fixing it. Of course, you need to be careful to maintain trust and rapport with the user while taking this approach.
5. Find out what someone is trying to achieve, before giving them a solution.
This is another time saver. Something as simple as “I need some AA batteries” can turn into time spent getting batteries and delivering them to someone, to find out they wanted them for their mouse which is dead, but plugs in to charge. Tying in with Rule 101, don’t assume the person asking for something actually knows that something will get them what they want.
6. Show pride in your work, but don’t brag.
If you do something good and noteworthy, share it and be proud. That doesn’t mean you bring it up at any opportunity to point out how awesome you think you are. Encourage others who have awesome ideas to see them through too – we’re not in this alone. If you’ve been on the receiving end of someone you’ve perceived as bragging, it’s not pleasant. Avoid others thinking that of you and it’ll be a general help to getting on with everyone. Bragging is a bit difficult to define as it’s contextual and people may have different opinions, but my general take between showing pride and bragging is more around the message it sends – are you doing it in a positive ‘this is awesome!’ way, or are you doing it in a ‘I’m better than you, you suck and you’re wrong’ way.
7. Have people you can learn from, as well as teach.
There are rewards in both teaching and learning. Having people to learn from is the obvious part (and if you can’t find them where you work, find them elsewhere – online, user groups etc), but teaching has it’s own rewards. Having others that can do some of the things you know means that hopefully others can cover for your job. If you’re higher up in the chain, then it will hopefully lead to less escalations which gives you more time to do more challenging tasks.
8. Don’t waste time being a jerk.
An extension of ‘Don’t be a jerk’. Being a jerk is easy, and it won’t benefit anyone, including yourself. You can provide constructive criticism, disagree with others and pick up on other people’s mistakes – but do it with the right approach. Also, just like online arguing, don’t go online and just be a jerk to others. If you feel the need to do this, then have a think about why you spend your valuable, finite time on doing that? In turn, you should stand up for yourself and what you believe is right – and choose when you decide to call someone else out on being a jerk. Personally, I find it demotivating to engage in a lot of it, but that’s me. Do what you think is right and inspires yourself and others.
9. Understand the environment you’re in before trying to change it.
‘It depends’ is an answer often given tongue-in-cheek to any IT related question, but it’s still generally correct. If something breaks in an IT environment, it’s because something changed. If you can’t fully understand the environment before making a change, make sure you can roll back that change as easily and quickly as possible.
10. If you’re stuck, do something else for a bit, have a break or go ask for help (and often realise the fix while asking)
I’m sure most of us experience this regularly. If you’re hitting a mental wall then you need to change your approach. I’ve done all these things many times – realised a solution to a problem while explaining the problem to someone else because I’m all out of ideas, or given up on a problem for the day only to go into work the next morning, look at it again for 5 minutes and have a ‘brain-wave’ on what the issue is. Trial and error should help you see the way you work best, and don’t beat yourself up about it.
11. If you don’t know how to undo what you’re about to do if it goes wrong, don’t do it.
“What does this big red button do?” Don’t press it. When you see someone who’s really struggling with computer basics, it’s often because they don’t know what impact anything they try to do, actually does. They are scared of breaking something due to their lack of understanding. You should be too! Of course this means you should read up on it, ask someone else or test it in a lab environment. Getting yourself out of trouble is just as important (if not more important) than believing you know the right thing to do in the first place. Undoing can be just renaming a file before making a config change so you can switch it back quickly, or restoring from last night’s backup – any way you can get out of trouble.
12. Adapt to your dealings with someone. Visit vs remote, email vs phone, explain vs just do.
When two people are working with each other, ideally they both change a bit to work the best way possible. Often, that doesn’t happen. For your own benefit, learn to adapt to the situation in front of you. If you’re dealing with an issue, it’s an important skill to quickly decide how you’re going to deal with a problem. Some people will want to understand what broke and how you fixed it, and others will want to go get a coffee while you sort it out. Don’t expect to change people that don’t want to listen. Sure, give it a shot and you might get lucky, but going in expecting someone to pay attention to you will just lead to frustration when they more than often, don’t.
13. What someone is asking for may not be what they are trying to achieve.
“I need Adobe Creative Cloud Suite, can you install it please?” might be the question, but the goal of what they’re trying to achieve might be a one time edit of a PDF. Maybe they already have different PDF editing software, or maybe someone else has it and can do it for them which is a lot quicker and cheaper than installing and licensing a product. Or maybe, they also had the original Word document and could just make a change there and reprint the PDF. I’ve seen a lot of time wasted when someone assumes the requester knows what they’re asking for and why. This does tie into #1, but it’s worth pointing out.
14. Respect all roles and people
I don’t care if you’re a receptionist or CEO, I’m going to start by giving you the time of day and try to help you. Sometimes, that receptionist (and I’m sorry to pick on this role, it’s just a good example of what people may consider ‘entry level’ and exists across most companies) is doing work for the CEO. You also might need help from that receptionist in the future, and the response you get may not be great if you didn’t respect them in the first place. More importantly, you’ll just get on with everyone around you better and in turn, should get that respect back. To reword a quote on this: “The true measure of a person is how they treats someone who they believe will do them absolutely no good.”. I’d also suggest not assuming that of anyone, everyone can do you some sort of good.
15. Ask for what you want instead of waiting and hoping.
Promotions, payrises, working on an interesting project or ‘no more apples in the vending machine’ – you should ask for something to greatly increase the chance of it happening. Maybe your boss doesn’t know you want to do certain work – telling them means they can hopefully make it happen in the future. Maybe not of course, but the wait and hope approach rarely works on it’s own.
16. Communicate lots.
Talk about what you’re going to do. Talk about what you just did. Choose whatever format works for you and who you deal with, verbal, email, wiki, instant message. There is a balance here to not be flooding people with information, but having it recorded and shared in any format is much better than no record at all. Even sending the “OK, thank you” email can have value to the sender to acknowledge what they’ve sent. Most issues occur from poor communication – almost every point I’ve listed here has some sort of relationship to good communication. Encourage others to communicate too, so you find out before something changes rather than after.
17. Keep it simple (and don’t call people stupid).
‘Short and sweet, to the point’ is a generalist statement on how I’d normally approach communication, especially when it’s a broadcast message. KIS also applies to technical solutions – don’t over complicate anything you do – the more moving parts, the more possible points of failure. Calling someone stupid… is stupid :) Sure, think it but work out how to work with the person, regardless of their ability level.
18. Critique vendors or services you pay for constructively.
Help vendors help you. Work with an account manager or whomever will listen and help provide solutions at the key vendors you work with. It’ll help in several ways – it will give a sense of how the company works and what they do. This helps you make decisions in how you use them, and even if you do want to use them in the future. You’ll make contacts and hopefully get better access when you really need it; say a critical event occurs and the fires are burning, being able to ping someone at the company who can quickly help is a huge benefit. You might also get access to new features earlier, as well as help shape how the product continues to develop.
19. Give positive feedback where it’s deserved.
Praise happens a lot less than critiquing sadly, but it should be done. I make a conscious effort to make sure positive feedback is given – especially if a bad situation has been turned around. It should mean a lot to whomever gets the praise, and make sure their manager knows too.
20. When you do things right, people won’t be sure you’ve done anything at all
Thanks Futurama for that one. Keeping things running will rarely bring any thanks or credit, but don’t let that discourage you. Take the pride in having services running (not servers, I don’t care about a server uptime! Service uptime which relates to user impact is what matters), and if you do want to show that off, produce reports showing that service uptime along with being fully patched – worth showing when the next major problem hits the news and you know you’re safe.
21. You’ll never know everything even on a single subject.
This can be a tough realisation – and it’s magnified with the new world of cloud and hyper super-accelerated rates of change. Knowing how to find answers, understanding new things quickly along with how it fits into everything else is a much more important skill than having a photographic memory of what every TCP port is used for.
22. Admit when you’ve made a mistake, own it.
It sucks when you do something wrong and then others have to find out about it, but it’s better than the alternative – others finding out you made a mistake and tried to cover it up. If it’s system impacting, fess up to what you did and either fix it or get the right person to fix it. Think of it as a learning experience, and hopefully you’ll never make that same mistake again.
23. Don’t ‘Automate all the things’
Complexity takes more time and has more room for error. Automation is great, where logic can be applied and the automation doesn’t take more time and resources than doing it manually – or at least a hybrid of manual and automation, such as a form that needs to be manually filled in with validation checks on the data, but then does something based on the data entered.
24. Appreciate that a lot of your job is to help others
A lot of IT (and particularly the non-dev side) at it’s core, is helping others. You’re doing IT work for someone else’s benefit, which in turn should be helping the business to make more money. There’s a whole essay I could write on this, but the main take away is to avoid getting frustrated at interruptions and instead teach that person what they don’t know… which might include telling them to speak to helpdesk first.
25. People yelling at you isn’t normal or healthy.
If a situation has gotten to the state where someone is actually yelling – do not engage. Definitely don’t yell back, and ideally remove yourself from the situation. This might be something more collective around ‘We’re getting worked up about this, let’s take a break and come back with clear heads’, or something much more direct like “There’s no need to yell at me. I’m happy to talk but not like that” – or however you feel is appropriate in the situation. If you’re too flustered to actually respond clearly, a simple “I need some air” or “We’ll talk later about this” can get you out of it to collect your thoughts.
If it’s an ongoing problem, speak to colleagues for advice, or HR. Nobody deserves to be yelled at. This of course gets much trickier if it’s your boss.
26. Don’t stick around under a ‘bad boss’.
This gets tricky. What makes a good or bad boss is more of a universal thing, but what parts of that bother you is going to be a personal thing. It might be fine for some if you have a boss that’s never around because you have plenty of work to do and get direction/feedback in other ways, but for others this can turn a good job into a bad one. You need to give your boss a chance and provide feedback on what you’d like out of them. If this doesn’t work though, you need to draw the line someone start looking for a way out if you really aren’t happy with the situation. Moving departments or companies is usually the go; change is scary but often good – and even if it’s not good, then just move on again!
27. People won’t change without help, guidance and feedback.
… and then sometimes they still won’t change. However, you need to give people a chance to grow and learn. Expecting someone to change what they do, how they communicate, what tiny process they seem to keep getting wrong will rarely change without someone giving them the hint. If someone’s decent at their job and takes pride in what they do, they’ll probably improve. Don’t just wait and hope for change though (#15), as you’ll probably be disappointed when nothing happens.
