IT and consulting. Two words that can conjur up thoughts of magic, awe and wonder. But like any other business, it has its challenges and you need to have your wits about you to survive and grow. Here are five things that I strive to do in this context.
Make time to learn
If there's one thing that's constant in IT and consulting, it's change. Yes, that's a cliché, but it's definitely true here. And unless you're happy becoming eventually obsolete, you need to keep learning. It doesn't come easy - days are busy, coffee breaks are a welcome relief where you can let your brain coast and process thoughts in the background, and in the evenings you're tired.
So plan in time for yourself to read. Have a focus on a certain topic or area, and make it your plan to work through all the material you can find. Set aside some "time for me" - it's not indulgent, it's a key aspect of being a good consultant. I'm an early riser, so after a run, I give myself 30 mins each morning to catch up on articles I've bookmarked.
Learning isn't just about reading of course, there's putting knowledge into practice too, and you have to make time for that as well. That might be at weekends if you find yourself with a bit of time on your hands, but it might just be as well while commuting, or an hour before the "main" day starts, say 0800-0900. Don't feel guilty - go for it. Nobody else is going to carve out the time for you.
(You may be interested to read this post I wrote about reading and learning: Tech Skills Chat with JonERP – A Follow-on Story).
There are so many articles on this subject I don't need to go into detail here. But I wanted to share a few of things I do in this regard that work well for me.
First, though - let's talk about attitude. Resist the temptation to be influenced by people who expect you to respond to an email minutes after they've sent it. Email is not work. Work is work. Email is communication - and asynchronous communication at that. Don't let them dictate your activities, and don't treat your email like a to-do list, because it won't be your to-do items on there!
So, here are the things I do that I recommend you do too. First, turn off all email notifications and alerts on all your devices. They only serve to distract you from what you're trying to do.
Second, discipline yourself to process email a few times a day. Don't have the email client running at any other time. This may be hard to do at first, especially if you're relying on your email client to remind you of meetings and events. But if you turn off notifications and minimise the client, that may be good enough. A side effect of applying this discipline is that it will eventually teach your colleagues that discipline too, at least in terms of expectations. And you can always send them (a link to) a polite note like this one: Email Discipline.
Finally, build a rule to handle your incoming email, splitting it on whether you've been directly addressed (in the "To:" list) or not (in the "Cc:" list). Divert to a "CC-Inbox" folder those emails where you've only been CC'd, and only check this folder once every two days or so.
If folks ask you do to something and they've not directly addressed you, that's bordering on rude. Resist the temptation to do it, and if they chase you on something, you can send them (a link to) a polite explanation like this one: Addressing Emails.
Managing email is not only about managing yourself, but about managing others.
Set reasonable meeting expectations
There are as many articles on meetings as there are on emails, so I can be brief here too. Time is the most precious commodity. Some meetings are necessary, but they're the minority, especially if you're technical and have work to do. Here's what I do. Not everything all of the time, but when it feels appropriate.
If a meeting is longer than half an hour, ask if it can be shorter. Resist accepting meeting requests that are over an hour, or reply tentatively saying you can make the first hour. Meetings that have the "luxury" of more than 60 minutes tend to squander those minutes and be almost naturally more inefficient.
Don't accept meeting requests that lack information (such as dial in details, or an agenda). You can send the requester (a link to) a polite note like this one: Meeting Request Details.
If I'm working at a client, I allow myself up to a maximum of two 30 minute calls. I can absorb this time into an earlier start, a later finish, or some of my lunch, depending on how generous or hungry I'm feeling. If I'm working at a client and they're being billed for it, it's not appropriate to use that time for other work. You shouldn't do it, and your colleagues shouldn't expect you to either.
Finally, don't waste your time if a meeting doesn't start on time. I usually wait for up to 5 minutes into the call (sometimes 10 minutes if I'm feeling generous and can work on stuff while I wait) and if it hasn't started, I'll leave the call.
Make time for lunch
I try to step away from the keyboard at lunch. It doesn't work all the time, and sometimes it's because I am putting some of my learning into practice. But your brain needs time to process what it's been working on during the morning, and it's not going to be able to to if you're still in front of the screen.
Stepping away is a discipline I learned from practising the Pomodoro technique (see the post The Maker's Schedule, Restraint and Flow), and I do find it helps to re-find focus, even if you're not thinking about it explicitly.
Also, lunch time isn't fixed. My day starts early, which means lunch for me is around 1130. That's great, because when I get back from my lunch, others are just going, which means a little more peace than the rest of the day :-)
If I'm honest, it's taken me a while to come to this conclusion. I've been fortunate recently to move into a position where I can look after a team of folks who are all amazing, technically and otherwise. And through my career hacking on SAP technology, it's been the people that matter.
I try to think what I can do to help them. Not all the time, I'm not that saintly. But when I can, when I'm mindful of what's important, I try to make time. I've been in this business for three decades now, and it stands to reason that I probably have some wisdom to share, even if it's "don't do that, I did, and it's not good".
There's this idea of being a 10x developer. I'm not sure if this is just mythical or metaphorical, but there's a simple truth in there which is that a good way for one person to scale is by making other folks better. And that's what I'm trying to learn to do now.