TL;DR: Ops is not passively actioning as many requests as you can at the highest velocity you can manage.
As an official ‘Ops’ professional for the last 2.5 years and, to some extent, unofficial ‘Ops’ pro for the length of my career so far, I’ve taken the time to write some reflections on ‘The Art of Ops’ (more art than science, I reckon). As with all good writing, this contains nothing original, and no great brave thinking. It’s a rearrangement of plagiarisms and near truisms. However, these things bear repeating, bear rearranging, and deserve genuine consideration.
Having discussed my impressive credentials and aims above, it’s perhaps worth explaining that I’ve found myself down the rabbit hole of ‘overwork’ many times, most recently about nine months before the writing of this article. I write not from a position of natural aptitude, but looking back at the trail I walked to climb out of the valleys and up to a better vantage point. Hopefully, with time, I’ll find myself with even better visibility and clarity that I can apply to my work. Looking back now, I can offer some reflection on what I learned.
I hadn’t noticed until prompted, but on reflection I began to understand that I had a stance on what Ops should be, how it should work, and therefore how I should work. I had this implicit assumption that a good Ops person is super responsive to requests from stakeholders. They don’t quibble or get in the way of the requests, they just jump to action and smooth out the ground in front of the staff they’re supporting. Ops is the team that removes barriers to ‘frontline’ staff doing their work. After all, who knows better than someone running a program what barriers are in their way?
I’ve come to view Ops as something rather different. Where before I was a lightning fast arm removing obstacles, almost unthinkingly (because priorities are set by stakeholders in such a way that I don’t need to think, I just need to act), now I realise I am a brain. Perhaps most people already know they have a brain and, as such, don’t need an article to tell them.
This perspective shift moved me from seeing my role as actioning requests from stakeholders as quickly as possible, to maintaining a bird’s-eye-view over the asks that I’m receiving and the priorities of the org. The important part here is that I’m not primarily responsive to the expressed priorities of a stakeholder, but rather to the needs of the org as a whole. Below, I will talk about the biggest (and possibly most counterintuitive) outcome of this reframing of the role of Ops, Pushback.
There will be times where you will have visibility that allows you to see that a request from a stakeholder does not carry the urgency and priority that they initially think it does, at least relative to the other work that you could and should be doing. This is not to say your colleagues are looking at all the relevant data and making an incorrect judgement. It’s pointing out that you have more data than they do about your competing priorities. You will hopefully better understand how your different projects fit the wider goals of the org you work for (you work for the org, not any individual team). This is the bird’s-eye-view I mentioned above. When you have a better vantage point, you should utilise it. There are times when I’ve been asked to action a task by a colleague who states that it is high priority, but when I give insight into my other priorities, they agree that their ask is not the top priority.
Another part of effective Ops work is being a subject matter expert. Your colleague making a request of you may come with a fully formed plan for implementation, but you will often know better. You may see an alternative route, or you may see a critical issue with their proposal.
The best way to push back is to consistently maintain a clear picture of what your current projects and priorities are[1], so that you can draw on this. "I can't do your request because I don't have capacity" can be unconvincing or unsatisfying, especially when it means that something that feels high importance to a stakeholder is going to be intentionally delayed or dropped. “I'm currently prioritising year end accounts” or “I’m assessing potential legal risk to a major contract that our CEO is due to sign by EoW" gives the requester the data they need to more easily update their priority rating of their ask. You’re more likely to get buy-in if you can explain your reasoning.
When I have to pushback and explain that I can’t action a task on the requested timeline, I try to either:
I have often found stakeholders’ responses to my pushback (in the form of an explanation of my other priorities) to be closer to "oh yeah, that makes sense, you should be prioritising that over my request". They don't have visibility into what else you're working on, so they don't have clear data for calibrating the priority of their request, they just know it's important to them. But your job is not to do what the individual wants/needs, it's to do what the org needs. Sometimes these two things will align, sometimes they won’t. The important thing is recognizing that they are distinct, even when they overlap.
Having confidently said that stakeholders will accept your pushback when couched in terms of overall org goals and priorities, it’s worth noting that I’ve worked at different organizations and have seen the way some orgs don’t have the same communal vision or goal buy-in. I’ve also seen the way silos within an org can form, or be drawn together into a cohesive whole. As an Ops member at an org, often interacting with teams across different regions/projects etc., you may have an opportunity to wield soft power and influence to support a transition towards better understanding and alignment. However, you may be at an org where warring factions are unlikely to band together. Perhaps in this situation, you might consider whether there’s an org out there that’s more aligned with itself in a way that allows you to work effectively. In my experience, there is.
I’m going to go out on a limb (despite being a brain) and assume that you already plan your work. With that assumption out of the way, I’ll begin my proselytisation about the importance of planning.
Have you heard the one about the woodcutter?
There’s a parable I recently came across. A woodcutter was challenged to cut down a great tree in 5 minutes. When the timer started, the woodcutter sat down and sharpened their axe for 3 minutes.
The lesson here is fairly straightforward. Don’t waste effort with blunt tools or poor technique. Don’t waste time moving in the wrong direction (or in circles) because you didn’t map a route. Don’t have the tree come crashing down on a nearby house because you didn’t think about which way it should fall. These are potential outcomes that you can avoid with planning and preparation. To draw more out of this parable, let’s make the numbers a bit more realistic for Ops work (maybe they already make sense for cutting down trees - that’s not really my bag).
It seems feasible to say that, for a project, you might spend one day/week/month planning for each 4 days/weeks/months you spend building/running a project[2]. So let’s use x to represent a time unit and suppose that for a particular project it makes sense to allocate 1x to planning/scoping and 4x for implementation. This would mean you could spend Monday planning and the rest of the week doing. However, obviously you likely won’t have only one tree to fell, and any trees in your way likely won't be lined up neatly with the exact amount of time for each allotted in your G-cal.
Proper planning is about scoping, not just executing your road map. The woodcutter should sharpen their axe, but they should also inspect the tree. "Ahhh, this is an oak. The request said it was pine, but now that I've taken one time-unit to review before swinging the axe, I can see it's oak, and I don't have time for that, because there's a tree in the next town over that needs felling, and that one absolutely has to be done by a certain date". The lumberjack is glad they didn't start chopping. They would have gotten part way in, had to stop and move on, letting some amount of their labour be lost. When they returned to this tree, they’d have forgotten some amount of the particulars of their plan for which way the tree should fall. They’d have to sharpen their axe again (twice for the same tree).
The point here is that you can (and should!) engage with a stakeholder and their project request before agreeing to action it. You can draft a timeline for consideration, comparing it to your other work and priorities. The outcome may be that you don't have time to chop through the tree. In this case, you'll likely want to see if they can work around this issue for some time. Over time, you will get better at communicating your priorities and understanding your colleagues’ needs. You will also likely notice that stakeholders get better at expressing what they need from you, start submitting requests in a format closer to what you’re looking for, and hold a better understanding of what they can expect from you. What I’m saying is that this process isn’t just about getting to the bottom of each individual request, but about improving communication between Ops and the colleagues that Ops aims to serve.
Another thing to bear in mind, with your eye in the sky view, is that, even if you have the time, is that how you should spend it? What does the org need you to do? I keep talking about how your job is not just to action all requests punted your way, it’s about intentional trade offs between tasks. Most jobs, Ops or not, will have more work than one person can do in the allotted hours. The key is to prioritise, ruthlessly if necessary, and work from the top down. I’m telling you to prioritise based on org-wide goals, not based on which stakeholder expresses higher urgency. There may be times when one request feels more urgent to you, but when you consider “what does the org want to achieve this quarter/year”, you realise you should focus on a different workstream. This is definitely true for me.
I recently asked my manager whether I should invest considerable resources into a project that is related, but not directly in service of, my usual responsibilities. In fact, it was for a team I don’t officially directly support. My assumption was that the answer would be a no. The answer was a “yes, and this is why…”; the why? Org priorities/goals. I don’t work for one team (even though, in many real ways, I do most of the time). I work for the whole org. I am a pair of hands, attached to a brain, and my brain should use those hands in whatever way is best for the org at any one time, even if it’s not business as usual for me, even if it conflicts with what’s normally my top priority. This is also an example of my manager modelling transparent reasoning (similar to what I suggest you do with your stakeholders). She explained why this particular project should go ahead, which put my mind at ease on this one project, while also reminding me of the way I should be thinking about asks from colleagues.
So the point is that Ops is not passively actioning as many requests as you can at the highest velocity you can manage (I didn’t even speak about sustainability of workload, but perhaps another time - I recommend a colleague’s article here on this topic). It’s about being deeply in tune with organisational priorities and aims at different levels and actively making trade offs, not just based on your ‘capacity’ but based on what you should be doing to serve the org. Engage with stakeholders to find out their reasons for the priority level they express for a certain request and be consistently aware of your own priorities, so that you can be explicit with them. Scope out tasks/projects before you agree to them, especially before you agree to a timeline of any sort. Pushback, or renegotiate, on requests. Be the brain, use the bird’s-eye-view, and sharpen your axe. Make potentially unpopular tradeoffs in service of the org. Be an artist, not a robot.
Thanks to the following colleagues for your review of my draft: Oscar Howie, Anna Weldon, and Toby Tremlett.
