Typically I am very organized about my day-to-day work, and also my short-term (3 months or so) planning. I use Trello for the “month” timeframe, iCloud Reminders for the “week” timeframe, and a paper notepad and pencil for the “day” timeframe. Sometimes, when I’m being particularly unproductive, I’ll even go into my calendar, either iCloud or Outlook, and break out my day. I don’t necessarily do formal Pomodoro(*), but I do break things into 1-hour chunks.
I started this system above about a year or two ago and my productivity has gone through the roof! I don’t necessarily believe in any one time management system over another, but I believe that doing ANY time management system will result in an improvement (the Hawthorne Effect*).
However…
- You have to be consistent…actually use the system for 90 days or so to give it an honest try
- You have the be intentional…actually try to use the system the correct way
And the most important…
- You have to be disciplined…actually follow the system rules on which tasks and for how long.
As with Pomodoro, or Kanban, or putting blocks of tasks on your calendar, or even a simple todo list, these systems only work if you actually focus on the singular task at hand and get it done (or at least work on only that task for that block of time). I know its hard; there’s always at least 5-10 other things in the back of your mind that you want to work on. It’s very, very easy for me, just in writing this blog post for example, to want to jump to another Chrome tab or an IDE and work on something else that is nagging my mind and is important.
When I walk around the organization and look at the team, what I usually see is each individual is busy and focused. Everyone has a lot of things to do on their plate, and believes that they are doing what is important and are busy. What’s interesting, though, is I can look from a position of having, perhaps, more broad contextual knowledge about the strategic perspective, and also what other teams are working on, and think to myself that they are not working on the true priority. It’s not that what they are working on isn’t important, it’s that there are other things that perhaps have more relative importance at that moment; you might be fixing a critical bug in a software app, yes, but that server you were supposed to get working, there’s a team of 4 other people at a standstill waiting on you.
Daily standups and taskings can help with this, sure. But again, what I’ve seen is that someone will get tasked with standing up that server, say a 4-hour task so let’s plan on having it done by the end of the day. But while standing up that server they notice the bug in the deployment scripts, start fixing that bug, notice that this module needs to be refactored, and the next thing you know it’s been 3 days and the server isn’t stood up yet.
From that engineer’s mind, they are busy, and what they are doing is important. You have to fix that bug and reduce that technical debt! But that 2 day delay now impacted that entire other team waiting on that server. An alternative approach might have been to get the server stood up, then gone back and prioritized (with the leads) fixing that bug and refactoring that module.
Scrum, Kanban, Sprints, even Pomodoro, all those systems only work if you very clearly define the task in front of you and then accomplish that task in the estimated time frame. And by defining a task, I mean defining that desired end state (“I need this server running”) and then working to that end state without getting too distracted. To be honest, for most people who are “crazy busy” a lot of it is because they are getting sidetracked with other things. Frequently the delays beyond estimated task times are because you let yourself get sucked in to too many rabbit holes, and what started as “stand up a server” turned in to “refactor 1,200 lines of scripting”.
I typically tell people, “Use your professional judgement.” When some side task appears, or someone asks you for help, if you feel like you can work it without too much of an impact then of course do so. I absolutely do not want to stifle the community of people being able to go to one another. But if someone hits you up and it’s a significant task, then you have to politely tell them that it has to be prioritized and it might be a bit until you can get to it, or maybe grab that person and go find your lead/ScrumMaster/manager/whatever and talk about it.
I call this “Engineering Discipline” and it can be very hard to establish this culture. People like to feel important, and they like to follow and pursue tasks that they perceive as interesting and significant, but by not focusing on the task that others are expecting them to do, the inter-relationships of all the tasks that people are working on can break down. This can be a very challenging thing to manage, but if you can focus on the day-to-day status reporting and be intentional about “managing by walking around(*)” you can help guide the team to great productivity and thus great success.
***
Holy Wikipedia Links, Batman!
Knuggets of Knowledge 
One thought on “If Everything’s a Priority, Then Nothing Is”