One thing about interviewing is that you get into the routine of answering standard questions. This has both an upside and a downside — it gets you to fully consider your philosophies on various topics, but you also run the risk of falling into over-rehearsed responses.
I was recently asked a pretty standard question: “In the face of multiple projects, how to you go about prioritizing your work?”
I like to talk about the tenants and rituals of iterative design development when addressing this question. In my experience, if I have the workflow aligned well, prioritization issues between projects tend to be an exception, which is exactly when I’d want to stop and pay attention to them.
But something about the flow of questioning and follow-up in this particular interview made me pause and rethink my answer. Maybe I wasn’t capturing everything that goes into addressing priority? Perhaps it wasn’t possible to do this with any brevity? Yet it’s still a question that deserves a solid answer.
It’s two questions.
There are really two questions here: 1) How do I manage and prioritize my daily tasks?, and 2) what is my philosophy when delivering to multiple clients?
For the first question, I can easily go into my preferred tactics of managing my day: keeping checklists, sequestering blocks of time for focused work, publishing my personal schedule and task timelines. But I’ve found that everyone has rather strong opinions around this. It is, after all, personal time management, which is always bespoke. The last thing you’d want to do in an interview is sing the praises of OneNote to someone who really doesn’t like it (I like it).
For me, when I’m interviewing a candidate, a personal task prioritization philosophy is one of those ‘box is checked’ things. I mainly want to see that they actually have one, and can talk about it, regardless of what it is. I like to hear about time management, flexibility, self-directed productivity, managing deadlines, that sort of thing.
But I believe that discussing a philosophy of prioritization among competing stakeholder projects deserves a bit more.
Know the mission & scope to the problem.
Prioritizing work is one of those things that is monumentally contextual, and something that every organization (that is being honest) struggles with. In a landscape of competing obligations, opportunities, and risks, how do you deploy resources? And how does that scope down to the individual contributor?
For individual contributors, I believe prioritization is necessarily a top-down affair:
Know the mission.
In many ways, the declaration of priorities has already been made: understand and know the current goals of the organization as a whole. Mission statements and org goals can sometimes feel like aspirational sloganeering, but in a good organization, real data has gone into those statements.
Also, know the goals of your group within the organization’s mission. Keep these in mind and refer to them specifically in any prioritization discussions. These have usually been developed through a deliberative process, and colleagues generally will agree that negotiating them can be counter-productive. For this reason, triaging priority clashes against the overall mission is a good place to start.
Understand how you personally advance your group’s mission. Every team ought to have a clear understanding of what they are delivering and how it can be measured against the progress of the organization as a whole. Without this, it is far too easy to work on the wrong things (or right things at the wrong time).
Stay problem-focused, and consistently scope work to the problem being solved.
To me, this is the big one.
Maintaining focus on the problem that is being solved allows teams to use one of the more powerful prioritization tools available: delivering solutions in iterative phases. Priority clashes are usually a question of who will get their request filled first. The ability to deliver value sooner is often a matter of breaking a large task into concrete deliverable phases. Where there are competing priorities, this can often allow you to deliver some progress on multiple fronts, rather than pausing one initiative entirely to advance another.*
In order to phase a task, a well-framed problem statement is imperative. With this, you can more easily identify when work should move up or down a priority stack. Plus, in this process, it’s possible to discover that a task can’t be segmented, and has to be delivered all at once to derive any value at all. All of this helps along the decision process.
It also requires more active management of stakeholders’ expectations. When successful, it strengthens working relationships. Few things build trust faster than reliable phased delivery of large tasks. Progress down a roadmap is satisfying for everyone, and meaningful progress on multiple fronts can be a good sign that you’ve gotten priority right.
* I realize I’m touching on agile principles here, but thinking about delivering value iteratively can be powerful all on its own.