Have you ever had one of those days? You’re interviewing for a job. Is it round four or five? You’ve lost count, but you’re enjoying the conversation, the interplay of professionals sharing experience and learning about each other. And then it happens. Your interviewer asks a question and the connection between your brain and your mouth just shorts out. You hear the words coming out of your face and you have to ask WTF?
I hope you haven’t had one of these days. I did and I’m writing this column to exorcise some demons.
The question was “How do you prioritize your work?”
Priorities. You need to set them and heed them. Otherwise, chaos reigns. For example, I hear that breakfast is the most important meal of the day. However, if you’re pressed for time, you should reconsider its importance. For example, see how your day goes if you prioritize your bowl of Wheaties over getting dressed. Breakfast might be a high priority, but clothes are higher.
And that’s the crux: given infinite time and endless resources, all items can be top priority, but introduce deadlines and resource bottlenecks, and you have to make some hard decisions.
So how do I make these decisions?
I take a reductionist approach, boiling down the process to inputs and outputs. The inputs are my data sources and constraints. The outputs are my goals and priorities.
Surveillance
To start, let’s take a look at my data sources. I can’t rank them by importance. I wish I could. Circumstances are too varied and the process is too nuanced to force them into a strict order.
Tracking tool: Your organization should have a tool for planning and tracking work (or multiple tools, that vary in effectiveness and use). This is usually the first place I look when sussing out priorities. I don’t take my tracking tool’s issue boards and reports at face value though. Those outputs are only as good as the data they’re sourced from, and the quality of the data varies greatly depending on who originates and maintains the information. Also, there’s always a gap between the current state of development and the state shown in the tracking tool. I never set priorities and start work without some light canvassing of product owners and developers to close that gap.
Your manager: Ideally, you report to someone who works with you to set your priorities and goals. Even if you don’t have an informed, involved manager, you can usually find someone in your organization like a peer, senior management, or executive who can vet either your priorities or your source data.
Executives and senior management: Executives are the elemental potassium of the tech writer’s world: essential to life, but highly reactive and requiring careful handling. Executives drive your organization and provide vision, but they focus on strategy, not tactics. Their view can be far removed from the reality of what’s actually being built now. If an executive sets your short-term priorities directly, be careful. Always test and verify. For example, I worked closely with a CTO who told me pointedly, “Don’t waste your time on [Product X]. It’s not going anywhere.” What he told me didn’t align with any of my other priority-setting inputs. I quietly continued my work. Three months later, when the CTO asked me “Phil, do we have doc for [Product X]?”, I was less than a week away from delivering a user guide and context-sensitive help system.
Users: Users and their needs should be the driving force behind everything you do. We tech writers are the users’ advocate after all. Too often writers are insulated from users, which is a crime because your users can raise priorities that you wouldn’t otherwise know about. For example, we published a special guide for an important chunk of functionality. We congratulated ourselves for our enlightened perspective and set our sights on the next task. The volume of support tickets snapped our attention back. Some users were inspired enough to tell us how much they hated the new guide. Doh. Time to reshuffle our priorities.
How are you getting your user feedback? I put more weight on direct user input from feedback tools, analytics, and support tickets. Less so input from other teams like sales and marketing who can color, filter, and amplify user feed with their own biases. The salesperson needs a monograph to close a sale, but is that the best use of your time right now?
Lead engineers: Much like noncommissioned officers in the military, years in the field have left lead engineers with well developed survival instincts. They have unparalleled knowledge about how things are built and their current progress. Technical leads’ perspective can help you keep your priorities in line and your sanity intact. This perspective comes with a caveat, however. Their tactical authority can exceed their strategic vision. The squeaky wheel gets the grease and sometimes technical leads can squeak really loud for resources. On one hand, I love it when a senior engineer lobbies me for docs for their work. On the other hand, you can spend a lot of energy on a pet project to the detriment of more important work.
Product owners: Often they’re lead engineers who either sought out or were pushed into management. Good ones combine that trench-survival knowledge with a higher operational awareness of the product in context of your company and the market, and how things get done organizationally in your company. These experts can help you keep your priorities straight.
Project managers: If you’re lucky enough to work on a team with a dedicated project manager or scrum master, you’ve got a source of high-value surveillance. They aren’t the folks making decisions, but they are a party to nearly every meeting and conversation where these decisions are made. A quick conversation can yield really valuable information.
Your gut: When it comes to folks who lead with their gut as a matter of policy, I agree with the character Rob in Nick Hornby’s novel High Fidelity: “I’ve been thinking with my guts since I was fourteen years old, and frankly speaking, […] I have come to the conclusion that my guts have shit for brains.” I want decisions to be objective and data-driven. However, I’ve spent too much time in the trenches to disregard my tech writer’s “Spidey sense”. As you gain experience with your craft, your users, your industry, and your organization, you can trust tech-writer sense more. For example, say you haven’t heard from a product manager recently. Is this because their product is winding down and is a lower priority… or are they working on a stealth project that will need documentation within a week of the upcoming press release? Either way, listen to your tech-writer tingles. They can save a lot of grief.
What you want to do: Don’t forget to prioritize your own health, happiness, curiosity, and professional development. Ask yourself, is there a class you want to take? A conference you want to attend? If you manage other writers, this goes doubly for them. Regularly poll your writers. If your company is enlightened enough to have a budget for professional development, make a priority of using it. It won’t get work done any faster in the short term, but in the long term you and your team will be more capable and resilient. The kind of work that tech writers do is not sustainable without these writer-focussed priorities.
Constraints
All these data sources are just half of the input. What are the constraints? What are the conditions in which you need to make decisions about what you’re working on?
- Schedule: When does it need to be delivered?
- Budget: Do you have the capacity in person-hours and cash to do it in the required time?
- Technical depth: Do you have the knowledge and expertise to do the work?
- Tools: Do you have the tools to create, deliver, and maintain it? If not, do you have the budget, schedule, and technical depth to get the tools and apply them effectively?
- Motivation: Are you excited about the work? I always want to do the fun stuff before the boring stuff. I’m sure I’m not alone in this. Luckily, my definition of “fun stuff” is varied enough for me to stay highly productive. I’ve never missed a deadline because of this, but enthusiasm is directly proportional to responsiveness and should be factored in when setting priorities.
Output
So now I have a big pile of inputs, both the surveillance and the constraints. How do I derive my priorities?
Like so many things in life, the answer is “it depends.” With so many variables in play, setting priorities is not a deterministic process. Some inputs will rise and fall in importance from time to time and from project to project.
In this way, setting priorities is like driving a car. Your starting goal is to get to your destination. You have a map–or GPS– so you have a plan. You don’t just mash the accelerator while keeping your eyes on the map or phone. What about other priorities, like avoiding a crash? You’re constantly adjusting your speed to keep up with traffic, making continuous, small steering corrections to make sure you stay in your lane. Driving has its constraints as well: Do you have enough fuel or charge to make the distance? What are the rules of the road for your trip? Are there even roads built to your destination? It can all feel a bit overwhelming at times, especially for a new driver or before a big road trip.
If you feel lost, remember to pull over and ask for directions.
Like driving, setting priorities can be intimidating, but the more you do it, the better you get.
What was my answer to that interview question, the one I flubbed so thoroughly? I feel like this column has reset that timeline, so I’ll leave it to your imagination.
