On a recent random coffee call (a form of networking I happily indulge in once a week) the following question came up. How do you take part in (run, team-lead, handle, manage and even code) 10+, 15+ projects without going cuckoo? And I was like: right, how?
I mean, there I am in my channel singing songs about time tracking. So it's probably not all sunshine and rainbows. But I'm holding on somehow.
As I see it, the main difficulties are three things:
— context switching,
— the constant stream of messages,
— and the general lack of time, of course.
Obviously, we're talking about projects that don't take 30 hours a week of involvement each. Otherwise it's all pointless, and the cuckoo flies off to warmer climes without us. Still, they do take quite a lot.
Long story short, over the years of all this parallelism I've developed some habits, and that's what I'm going to write about. Hard to say how critical they are, but without them my cuckoo and I would have a hard time fighting these difficulties.
Context switching
They say it's the most expensive operation in development. Among the basic ones, of course.
At least, back when people wrote low-level libraries in assembly, that was the case. The computation itself takes an instant, but all the rest — preparing the data, setting up the channels, shuffling everything back and forth across the stack and registers — takes forever.
In our case, context switching means changing projects during working hours. You have to take everything you've just been doing out of your head, store it carefully somewhere, and put into your head the state of another project you were doing earlier. And work on that. What's more, you have to perform this operation yourself, without the help of Dr. H. Lecter's steady hands.
All in all, it's hard and draining. So the first thing to do is to minimize context switching. For example, by dropping 7 projects out of 10 To do that, you need to group tasks and plan when to do them.
If, say, 5 of 10 projects are a team lead role in development, with sprints, in Jira, then the work happens in tickets and it happens reactively. Somebody wrote something — you have to react. Do a review, answer a question, give an estimate, or write up a concept. These are usually short tasks; sometimes switching to them takes about as long as doing them. What should you do? Group these tasks into a single "sprint" of an hour or two, and instead of reacting quickly to each ticket separately throughout the day — react to a batch of tickets at once. Say, in the morning and in the evening.
It's possible that some abstract project manager would stab an abstract team lead in an abstract back alley for such good advice. But right now we're talking about how a team lead can avoid going cuckoo, not how to please the PM. Besides, what can he do to us, he's in another city anyway.
Of course, you shouldn't forget about the SLAs stipulated by the contract, the employment agreement or other sworn working conditions — for example, answering tickets within 3 hours during working hours, or responding to blockers (critical tickets that stop the work) within half an hour. But even with such conditions it's quite feasible to group tasks and process them in batches, and the PM will be happy too.
And if you do that, you can quite realistically set aside 2–3 uninterrupted hours in a row for the projects where you need to code (or think, or write a long spec). And then development gets going, at least until our process is invaded by
The stream of messages
Projects, whether you're a team lead or in any other role, constantly generate communication. The main thing not to do is drop everything every time your email or Telegram dings (mute it, by the way) and run to Jira to see who's making noise this time. Don't get distracted. You'll look when you get to that project. Or when you go for a coffee, if you've got nothing better to do over coffee.
By the way, tools like Jira (or YouGile, or other trackers) are our friends, whatever anyone says. They can be slow, buggy, bloated with features, whatever. But they are exactly what gives us good snapshots of the state of our projects. What happened, what's happening now, what to expect. If you're running some project solo, you can do without them (although you'll still have some kind of tracker). But with a team — no way.
In general, you really need to learn not to answer messages right away when you're busy. A simple exercise helps with the training, by the way — when you get a work message, just don't reply for at least five to ten minutes. Even if you're not busy (why aren't you busy, by the way?) — still don't reply. Practice. And if this training comes easy, it has a bonus level: get yourself a client who follows every messenger message with a phone call if there's no reply within 2 minutes. I had one like that — excellent training. "Why aren't you answering?! It's urgent!!! I need an answer right now!!!" — or something like that is what I might have heard if I'd picked up.
Perhaps by now there are several people waiting in that abstract back alley to have a word with the abstract team lead with such good advice.
To reduce the stream of messages, channel it somewhere useful, and maybe make working with it a little easier, try introducing your especially talkative colleagues to some communication tips. For example, these ones. And then, in a given project, you might manage to get into
The flow state
Oddly enough, it's not only our friend but also our enemy. It's wonderful when we get into the flow on a project and solve tasks one after another, and everything works out, and we'll just knock out this thing too, and that one over there! Not so wonderful when you come out of this state two days later, having done a lot of stuff, and remember that you seem to have been doing something else before… Ah, yes, there they are, 120 messages on other projects.
When you have many projects, you obviously can't do that. So it's highly advisable to put clear tasks with set time limits into the flow. And when the tasks are done —
And when the time is up, you also have to stop, however disappointing it is. And go do other work.
That's why I usually schedule the tasks that pull me into the flow for the evening. So that I can get carried away and code all night, and nobody would judge me for it… Well, except my loved ones, whom I'll be growling at the next day after not getting enough sleep. So it's better to avoid night-time flows too, yeah. But it doesn't always work out, because of
The general lack of time
No matter how much you group tasks, no matter how many colleagues you ignore in messengers, there won't be any more hours in a day; you have to work with what you've got. And this is where, classically, planning and prioritization come to the fore. You need to keep notes, task lists, you need to rank and schedule them, and of course this shouldn't eat up half of every day. How exactly to do it, with what tools and on what principles doesn't really matter, I think. The main thing is that it's convenient and clear. As good old David Allen said, when choosing what you're going to do now, it's important to see the list of what you're not going to do now. Accordingly, the tools have to solve this important problem.
My tools have evolved over years of work and basically solve the main problems: I can see what needs to be done, when it needs to be done, and what to pick right now. This system of mine, as A. Nimzowitsch might have put it, is described here. But the details of how it works don't matter much, the main thing is that you have one.
Besides, to make my life easier, I try to follow some principles and, where possible, introduce my colleagues to them. This keeps clients in a state of joy, and also encourages colleagues to inflict this joy.
And, of course, it doesn't hurt to do some
Time tracking
Tracking the time spent on projects is useful. First of all, so you can not just reflect on the past work week, but reflect with the facts at hand. What actually happened:
— you were generally lazy and so got nothing done?
— you spent too much time on blog posts your personal brand and chatting in chats networking?
— project B ate 70% of your working hours and there was nothing left for the rest?
I do this practice on and off: while it's useful — I measure. Over time I notice that time tracking isn't doing any more good — I stop. Then doubts arise — I measure again.
And, in lieu of a conclusion
The most important thing
You always need to know when your cuckoo is at its limit. When it's time to answer the question of whether you want to take on a 129th project for 5 hours a week with: sorry, the box is full, little pot, stop cooking. And not take that very project.