OmniFocus and GTD for Technology Team Managers

In contemplating how to frame an article around how I use OmniFocus for work it started becoming obvious to me that the type of work I do makes a huge difference in how I use the tool to begin with.

As a technology team manager, I oversee several teams of software developers who write and QA software that runs the gamut from iOS application development to database application programming. At any given time there could be two to three major projects running across several large teams or a more fragmented approach which might encompass a dozen simultaneous projects in various stages of completion involving just a single resource.

Despite this abstraction, my daily work still involves working through discrete action steps. Work projects rarely involve the type of hands-on things that I might track in OmniFocus for home projects, however. The things I generally need OmniFocus to help me with for work involve reminders for sending critical emails, scheduling meetings, following up on requests, preparing for meetings etc.

One of the general things that is thrown around a lot in blog posts about productivity is something like "if it was truly high priority you wouldn't need a reminder", but I think that's bullshit. When you have several projects going on at once, all needing at least some portion of your attention, it is very easy to lose critical threads as you context-switch between all of the things that go on in a typical day's chaos.

How Do Technology Managers use Task Manager Applications?

In the past few years, I haven't had a day when I didn't meet on at least two ongoing projects. Usually it is many more than that. All of the projects are in varied states of completion. Some of those states might be:

"idea" stage
business concept
business requirements
technical requirements
QA planning
troubleshooting
risk assessment and management
budgeting
resource planning

That's just to name a few. In each one of those little meetings -- it might be a simple hallway conversation or a full-blown project kick-off meeting lasting hours -- the goal is to come out of them with actionable, trackable responsibilities. While the project manager for each project will be tracking individual tasks, I am responsible for seeing my tasks to completion and my method of keeping track of those things needs to be bulletproof.

As I've written about extensively, OmniFocus is the key to all of these things for me but I've found that I use OmniFocus a bit differently than other people and I believe that owes simply to my role as a manager. Rather than write something about how everyone should use OmniFocus the same way, irrespective of their role, I thought it best to go in depth with how I use it given what I do.

So, for some of you, this won't make any sense and using OmniFocus or GTD this way will likely lead to some confusion. I doubt the way I have outlined below will work for you if you're a teacher or a project manager, for instance. It might lead to some interesting ways to think about how you use the tool, however, so at least you'll get some new perspectives if you happen to wade through what will likely be a very long post.

The Importance of Contexts

One thing that was a bit of a revelation to me, after the initial three week period of hammering out a viable GTD workflow to help me with work, was how major a role Contexts played compared to Projects. To review the basic concepts on these and how most people use them, refer back to my earlier Beginning OmniFocus posts on them.

As a technology-based manager, however, my need for Contexts runs a bit counter to the ideal. I use Contexts throughout the day to focus myself depending on where I am, what I'm doing or who I am talking to. I touched on this point briefly in my Context post but today I'll go into a lot more depth.

I have the following Context types:

Team/Person Context - These are arranged hierarchically with team names defined as a folder and then team members rolling up to each team type. I have "Dev", "QA", "IT", "Management" and "Peers" with people defined as Contexts below each. If I have an item to cover in a QA team meeting, I'll put it in the general QA team context, but if I need to speak to a specific team member, I'll assign it to their individual Context. These are helpful when I'm in a hallway conversation with someone about a specific project and I have a few other things that they need to know about. Each item that I need to address with them is under their individual Context. Obviously this wouldn't work with huge teams but I work at a small company and this works out really well for me.
Stakeholder Context - These are also based on specific people but I keep them in a Stakeholder folder given the disparate teams they may belong to across the organization. These are tasks that I need to complete when speaking with or interacting with them directly (fact finding, spec resolutions, etc.)
Location-based Contexts - Work, Home, and Phone are the three that pertain here although things like Home and Phone can pertain to Home-based projects too. Here's where we start seeing the strength of the GTD Contexts. If I am at home and have some spare minutes to get my phone calls out of the way, it is useful to see them all listed in one Phone context.
Standing Meeting Contexts - I have created Contexts for weekly/monthly standing meetings. I add items to these when I know there are topics I need to cover in those meetings and don't want to lose track of them. These items become my agenda prior to the meeting.
Email/Computer - Any items that I need to research, emails that need replying to, websites that I need to read get filed here. So when I'm replying to email, irrespective of project, it happens when I'm taking care of my "Email/Computer" Context.
Management - This is another person-based Context which is a catch-all for anyone I need to deal with politically, cross-departmentally or otherwise. My boss is in this group as well as other SVPs across the organization. It also contains peers and people I might require to resolve organizational needs like HR and Finance.
IT Context - A person-based Context containing IT personnel who are pivotal to completion of projects or resolving issues that members of my teams might be having. These types of items can take time and a lot of back-and-forth to resolve so having them in a specific Context keeps me following up on them often enough to get taken care of.
Thinking - As I wrote a while back, this is a very untraditional Context in the GTD methodology but I use it to file away things that I need to lock the office door to think, whiteboard or brainstorm about. It doesn't get used that often but having this catch-all keeps it from getting lost in a sea of other tasks in more targetted Contexts.

As you learn after doing GTD for a while, Contexts are the single-most important construct in the GTD methodology. After you spend months looking at things in Project view, as long as you haven't ignored Contexts completely, something will click and you'll understand how incredibly useful they are and why, once you've used them, using a bog-standard list of "Things To Do" in the Reminders app just doesn't cut it anymore.

Well... Then What About Projects?

Projects obviously have their place but because GTD isn't a project management methodology and because I'm not a project manager in the strictest sense they take a backseat to Contexts when it comes to actually working on things. Projects still are necessary for me, however, so don't think that I threw the baby out with the bathwater. It is just that I think about them differently than in the typical GTD sense.

When a new project is announced, I create a Project for it in OmniFocus. It is basically a dropzone for new tasks before they get Contexts assigned to them. It also helps to set something up like this early on in the project lifecycle because you can do a full GTD "capture" about the project, cataloguing all of the things that you need to do to get the project off of the ground (things like assigning resources, checking project timelines for conflicting due dates, vacations etc.)

It is fine to add a project, give it a descriptive name (or a codename) and leave it empty until you can think of things to add to it. The typical project in GTD is one where you can define the goal and break it down into a series of actions but, at this point in a project lifecycle, that may be a waste of time. Given how little you know about what the completion state is, it's not really feasible yet. What will generally happen as the lifecycle moves forward is that sub-projects will present themselves -- ones that require discrete actions steps to complete -- and they will take up residence under each Project. I suppose you could say these capital-P "Projects" serve as overarching buckets into which many sub-projects will live, each with a singular, defined conclusion and all playing a part in marching the project towards completion.

The Project is also key when doing Reviews. They are a good place to take a focused look at all of the things you're on the hook for (the "what") related to a given project, regardless of Context (the "how" or "where").

Reviews Are Your Friend

Reviews are essential to the care-and-feeding of a typical GTD workflow. As I laid out in my previous article focusing specifically on Reviews, doing a full review can have the feel of a reset when things are getting a bit ragged around the edges. As you scan through your tasks, deleting and adding new items as needed, you get a more well-rounded view of your project and also give yourself space to think outside-the-box on items that may have been escaping your purview when wallowing in the trenches, day to day.

I generally cycle through a variety of review types. They all have their place and some are more important than others at different times in a project's lifecycle.

Project - Project-level reviews often happen in the other review cycles as well but, more specifically, they happen during project status meetings. These meetings present the ideal time to cross tasks off of the list and interact with individuals you have created Contexts for (developers, QA folks, stakeholders and project managers). You can even use the tasks outlined in your project as an agenda if called upon to do so, checking in with each contact and crossing things off of your list when you verify they're complete. It is a good time to go about adding tasks you will be responsible for as the project reveals itself over the intervening weeks or months. The worst thing that can happen is that you don't capture a critical item and the project ends up getting delayed because you didn't meet a responsibility. This can present an opportunity for a real life case of "GTD to the rescue". Between your trusted capture system and an approach to the review process that keeps things front-and-center, you can virtually eliminate this type of thing from taking you by surprise.
Daily - Every morning I check my "High Priority" perspective to see what is critical for a given day, but I also spin through the project view and get a sense of things that might be upcoming. If I get some time amidst the higher priority items, it's sometimes useful to cross some of these off the list as well before they become an issue.
Weekly - Punctuating the week, usually on Friday morning, I do a full weekly review of everything. All home and work Projects get examined and tweaked as necessary. It sounds like a lot but, if you've been doing your daily reviews, it usually only takes a few minutes.

As I mentioned in my Review article, deleting tasks is just as powerful as adding them. It becomes even more pivotal as you function in a managerial role. It also grows in importance simply because you're aiming at a moving target with development projects -- often the state is not completely known at the project's inception and, adding to the complication, it is also changing on a daily basis.

Like the saying goes, project management is like trying to shoot a bullet with a bullet. The best defense against being out of sync is to delete things that don't matter anymore and add things the second they reveal themselves. The Review is the single best time to do that.

In the Trenches

As you can see, all of these OmniFocus articles I write build on each other. They are all describing a comprehensive methodology that took a few years to arrive at and was adapted to serve my unique needs. As this website evolved, the feedback I was getting from readers led me to believe that perhaps my needs weren't all that unique.

Many of the GTD books and articles out there point you towards this ideal set up where we have example projects like "Mend the roof" and such. These types of projects have fairly well-defined action steps and the end result is clear -- a mended roof.

Software development is a messy business. Development projects don't appear, pre-formed, with a clear view from the first step to completion. Often, when new opportunities arise, the completion state isn't even known. In that case, having a flexible and adaptable system that allows us to manage the disparate pieces of the project for which we are responsible can mean the difference between "shipping" and an over-budget, delayed nightmare. It also keeps our finger on the pulse of the teams and stakeholders involved which is a key job of the manager.

That said, where software is concerned, there are only so many parts of the process which we can hope to control. Stakeholders often interact with clients who rarely feel the pressures of time and expense and for whom it is easy to make demands that exceed the bounds of both. Specifications can take longer than anticipated to complete which will, in turn, hinder your team's ability to generate technical requirements and test plans. Each step is a link in the chain and, as a technical manager, your job is often to simply put your team in the best possible position to succeed despite all of these issues.

Putting a workflow and methodology in place like the one described above is not the only way to do it, but it is the one I've arrived at that works the best for me. Hopefully you can find something in that heap of words that can help you too.