What Counts as Important Work

From time to time I have encountered a tension between what is considered important work. In my experience, work tied to a formal project or to business goals is often deemed important work, and other vital work is de-emphasized. We still need to honor and respect the vital day-to-day work teams do to keep the lights on.

Why does what counts as important work matter?

Important work gets the resources, the respect, and value of the team or the company. I have seen vital, necessary work get deprioritized because it was not "important" work that lined up neatly behind a project or initiative the company thought was valuable. I have found that when you ignore vital work that is exists outside of a project or roadmap item you introduce rot/decay/entropy into your organization or your systems.

Your team and your business require consistent maintenance and care in order to continue functioning. Sure, you may be able to get by without maintaining yourself in the same way you can continue to use a machine without maintenance. However, you can generally expect a decrease in efficiency if not outright breakdowns eventually. This lack of maintenance often manifests in the technology industry as technical debt, faulty or unreliable infrastructure, or burnout and dissatisfaction among team members.

We need to find a way to understand how the day-to-day, recurring maintenance and care is important, vital work that aligns with the business's big objectives instead of viewing these activities as cost centers or wastes of resources.

This question is also very important to consider because people's livelihoods and careers depend on whether or not the work they do is perceived as important. Work that is not viewed as important may also be more likely to be assigned or delegated to employees from marginalized groups in some companies; this can limit their career growth and potential at these companies.

How do you understand work?

I'm not sure what a good definition of work is overall. I have some possible models, however, that seem to be useful in understanding how to approach different types of work. I have tried to stick to simple models as much as possible. You could model your work in any number of ways, but I find in many cases those ways can be collapsed into a smaller number of categories. I also believe fewer categories is easier to remember and to carry over into other areas, like team processes, work management software, tracking work, etc.

Developing a model for understanding your work is important, I think, because it informs how you represent your work in writing, in software, or mentally. How you represent your work is, in my experience, very important for cultivating a good mutual understanding of your work within your team, showing your work to team members outside of your team, and to promoting work as important to you, to your team, and to the business.

Projects and not-projects

The first model is dividing work into projects and not-projects. Projects are generally relatively neatly defined with a clear intended outcome and a timeframe in which work will happen to deliver that outcome. In addition, once a project is done, it is ended. Subsequent work is either done on an ad-hoc basis or in a follow up project. Projects are also usually aligned with some bigger business goal or objective the team or the company is trying to achieve. Constructing a building or writing a specific release of some software feel like good examples of projects to me.

Not-projects are everything else, especially work that is recurring, not clearly defined, or occurs continuously over an indefinite period of time. This work is often critical to the team or business but is not considered a higher level goal or objective of the company. This kind of work to me includes but is not limited to supporting customers, responding to email form submissions, updating the software powering your infrastructure, and ad-hoc troubleshooting and bug fixes. They are the day-to-day work people do that keeps the business going.

While this provides a somewhat neat division of work, this model often results in projects receiving the attention and resources of the company at the expense of not-projects.

Continuous work vs non-continuous work

Under this model work divides into work that is performed on a continous basis or commitment and work that is only done for a specific period of time after which the work stops in its current form.

Continuous work would include but not be limited to regular operations, day-to-day meetings and activities, periodic maintenance, fulfilling the requirements of long-term contracts and commitments, responding to technical support requests, engaging with customer inquiries and contacts, and monitoring the health of the company.

Non-continuous work would be activities like new software development, deploying infrastructure, non-recurring meetings and initiatives, one-off or infrequent events, developing specific releases of software, or roadmap items.

I think this model can provide a good simple heuristic for classifying work to fit into other processes and systems. However, I think this model is also vulnerable to prioritizing the non-continuous work over the continuos work. I also think it is not very descripive or helpful outside of putting work in one category or another. That is, being continuous or not continuous doesn't tell you much about the work, whereas projects often have expectations around scope and timing.

All work is a project of some kind

Under this model of understanding, every kind of work is understood to be a project in some regard because every kind of work generally has a clear intended outcome and occurs within a specific timeframe. For example, responding to a technical support request usually aims to deliver a positive resolution for the user's issue within in previously specified timeframe. It has a specific outcome - a positive resolution - and discrete timebox - whatever the service level agreement sets as the expectation. This type of activity and other types of continuous, non-project activity canarguably fit within the definition of non-continuous or project activity.

While I appreciate this model places all work on the same level, I worry that it loses its value and meaningfulness as a means of classifying work and of more clearly representing work.

Roadmap items vs non-roadmap items

In this understanding, work is divided into tasks and activities that correspond to or align with the company's business goals and into tasks and activities that do not correspond to or align with the company's business goals.

Generally, the only criterion is how well does the work under consideration support the business's planned goals or outcomes.

Commitments vs non-commitments

Under this model, work is classified as either part of fulfilling one or more commitments we as a team have made to ourselves, to other teams within the company, to the company, or to people outside of the company or not.

I like this understanding most out of the ones I have listed so far. I think this one provides a really clear division between work that is important and work that is not important. At the end of the day, meeting the commitments we have made is what makes us successful. The commitments could be to deliver a specific type of service at a certain level of quality and timeliness. The commitments could be to complete roadmap items for the company by a specific point of time. The commitments could be maintaining a good quality of life for our own team members through maintaining in the tools, processes, and infrastructure we need to do our jobs.

I feel like this model of representing work provides a much more inclusive and expansive understanding of what is important. I think it places work that is traditionally undervalued on a solid philosophical footing for why the work should also be valued alongside project-driven or business goal-oriented work.

How this feeds into other areas

I am interested in this question because I need to clarify how to organize information in Jira mostly. I also want to be able to clearly articulate what work I feel is important so that I can better protect my time and the time of my team members. I feel if I have a well-developed philosophical underpinning for how I categorize and represent the work I do I can communicate why I am doing that work better.