- Plan ahead (with contingency)
- Whatever works for you – personal JIRA, Trello, stacked sticky notes, dead tree notebook
- Stay focussed
- Specify windows to check your email (e.g. first thing in AM and after lunch) and ignore emails until that window
- Rather than letting new tasks distract you, write them down, then continue on your current task – and have a time to review and prioritize those tasks during the day.
- Avoid context switching – humans are very bad at multitasking and your brain is highly prone to disk-thrashing, especially if you think you’re good at multitasking. See this TIME article for a summary of the research.
- Some people work best with time-boxing : concentrate on a single task for a fixed period of time. Read about the Pomodoro technique.
- Say No if you need to – or you’ll disappoint
- If someone asks you to do something, get a deadline for it to help you decide if you have time
- Track as you go
- 6 minutes are a good building block of time to decimalise your day, especially if you’re filling out timesheets.
- If you’re working on more than 1 project, you’re going to forget very quickly what you’ve done by the end of the week
- Review your time – find ways to optimise
- Personal retrospectives. Are you spending your time on what you should be spending it on?
- Learn when to delegate, both to management and within your team.
All technical leads should write code. If you’re not writing code, you’re a manager. And that’s fine. But stop pretending you’re technical. Many Technical Leads or other senior technical staff have a preferred time split between the admin and technical parts of their job, but I don’t always see that in practice.
Some technical leads double down on the technical part and ignore the leadership part. Those are the people who need mentored. It’s the hardest shift when becoming the leader, to accept that your most valuable time is no longer the conversation you have with the compiler, it’s the conversations you have with and on behalf of your team.
You need the time to have those conversations, to keep the team delivering, and delivering the right thing. But you also need up to date technical knowledge to give you the right context for those conversations.
Managing time can be one of the trickiest skills for a new technical lead to learn. The process I use is simple, but it requires discipline.
If you want a split of 60% coding to 40% admin, then schedule it in advance. Pick 2 admin days and 3 development days. Or if you’re most creative in the mornings, schedule 3 hours at the end of each day. Into the admin days put your 1-2-1 meetings and other line management, and your cross-functional meetings, and the team planning and retrospective meetings. Lay out time for emails and backlog pruning and catching up on your reading list. And then block the remainder off for development, deferring to your task board for detail. And make those events as public as you can so your team and others know when they can schedule your time.
Maybe those times are dictated by others and you end up with regular meetings scheduled in your Zone time.If you can’t move it, work the schedule around it. Turn those into your admin days. The most important thing is to define a split, and stick to it.
I’ve spoken before about how a quick time out to grab a coffee can help you get to the bottom of a problem, but sometimes you need longer. You need time to switch off and think.
I feel guilty about just sitting and thinking, despite trying mindfulness techniques, so for me, my best thinking comes when my body is busy but my mind is free. Sometimes in the shower (and apologies to my wife for those days when I take an extra 10 minutes to think through something), sometimes swimming, sometimes mowing the lawn.
Take time to get bored. Boredom is not boring. Boredom gives you ideas.
- in praise of boredom – Why boredom is anything but boring : Nature News & Comment
- How being bored out of your mind make you more creative
Action is good, thinking then acting is better. Make time to think.
Don’t write your own ORM, NHibernate and Entity Framework are probably faster, more secure and less buggy than anything you could write.
Don’t manage your own servers. Let Microsoft, or Amazon, or Google, or a myriad of other providers do it for you. Let someone else monitor the patch list, recover from failures and continually roll out new hardware.
You own your dependencies, but sometimes that’s better than owning a half-baked, home-brewed alternative.
Reducing waste is one of the key concerns of agile development, and is a defining character for Kanban, where blockages are ruthlessly identified and resolved. Timeboxing provides a low-cost means of identifying waste and a framework for tackling it, but doesn’t provide many solutions on its own.
For tasks that continually cause blockages, such as the release process, or testing, automation is a good way to eliminate the repetition, and the chance of human error. Indeed, the engineers in the audience will immediately recognise the key drivers for Continuous Deployment and Continuous Integration in the examples I’ve given.
And yet, whilst we appreciate the gains it can make, how many teams set aside specific time in their schedules for “automation” as an activity alongside “refactoring”, “upgrading dependencies” and “deleting dead code (including tests)”.
Check your backlog, and if automation, in some form, isn’t there, ask yourself why those repetitive manual steps still exist in your workflow and why they have priority over the other work you have to do.
Did you learn something? Did you stretch yourself? Did you challenge your assumptions, or your practices?
Do you feel like you achieved something last week? Did the frustrations inspire you to make it easier next week? Did you share them with others, in the pub, or on your blog, so others can learn from your frustration?
Did you set new goals? Are you going to be a faster typist? Are you going to learn functional programming? This time, are you going to lose weight?
Did you make new connections? Did you make an effort to understand the people you work with? Did you do something to strengthen your work and personal relationships?
You don’t have to do all of that. But did you think of it? Did you write it down? Did you, in some small and agile way, improve yourself?
Can you say to yourself, today, that you had a useful week?
There’s a few little things that sneak in to conversations and emails that you probably don’t realise you’re doing, until someone points them out to you.
No problem VS You’re welcome
Darlene Price has a great list of phrases you should never say at work. One that really stuck with me was replying to “thanks”, with “no problem”. It was something I did reflexively, either because I thought I was Australian, or because I wanted to minimise the work I’d done. As the article above explains however, it also implies that it would be a problem in other circumstances. Whilst that may be true, there’s an implicit “it’s OK, this time” vibe that, once I spotted it, started to come across to me like a passive aggressive threat. I don’t think that’s how it was perceived, but once I saw that, I couldn’t unsee it, so stopped using “no problem” almost immediately after reading that article.
You’re smart VS You worked hard
This is a parenting basic tip, but it’s a useful thought in general. If you’re smart, then you’re #1, so why try harder. If you worked hard, then you can see the effoer for your reward, and hard work is not a barrier to future success. If you’re smart and you fail, then you’re just not smart enough. If you worked hard and fail, then you either keep working, or seek help. It’s OK to ask for help if you’ve put effort in and need support. It’s not OK if you’re not smart enough, your ego will get in the way.
The modern workplace demands flexibility. Sometimes to accommodate work, because international companies need to work to international timezones. Sometimes to accommodate life. Don’t discount good staff because they have childcare duties, or other demands on their non-work time. 9 to 5 isn’t the only way, so long as people do the work and are involved in the right conversations.
To fit a good work life balance, your work should stay at work. My previous job supplied me with a laptop and rules, when working at certain desks, that I had to take my laptop home “for security”, and it became second nature to carry a heavy bag with heavy laptop, heavy notebook, and several printouts, because I’d need them.
- Travel light. Small notebooks are better, tearaway pages are better still.
- Don’t bring your own device. If a company needs you to access work outside the office, they will pay you to do so. Or at least give you reasonable compensation. They’ll have a sane home-working policy, or a laptop-installed communication channel. If you can’t use Unified communications, or at least VOIP, things should change.
- Treat long hours as a bug. Fix it. If the company can’t fix it, the culture is wrong.
- Antisocial hours may be required, but they must be compensated for in whatever reward suits the worker best. And planned ahead whenever possible.
But sometimes you just need to get something done.
Don’t be afraid to block out 30 minutes or half a day to focus. Put it in your calendar so everyone can see, and go somewhere private where you won’t get interrupted unless it’s an emergency. Work outside the office if you have to.
And limit your time. If you know you only have an hour (or 2 pomodoros) to finish something, you will be focused on it for that time. But pomodoros are good to remind you to take a break, re-energise and get back in the flow (but not Flowstate – I like the idea of an app that keeps you focused Mission Impossible style, but a lot of the writing I do needs a lot of thinking too).
Be clear about what you’re doing so that your team feels they have the space to do it when they need to.