Work about Work Stagnation

So this is something I have noticed both in organisations I have worked in, as well as once where people I know work, and it is something that intrigues me if it is universal, or if my sample size just is too small to notice its insignificance.

My observation

When organisations or projects no longer are able to generate real progress they start to focus on work about work.

What Is Work about Work?

I think that in general the term is reasonably well known within the tech industry, but for those that are unfamiliar with it, here is a short primer.

“Work about work”, is a form of work that typically generate thing on someone’s to-do list that only relates to the act of organising or preparing actual work. It is a form of meta work. Examples of these are work planning meetings, or tasks to prepare the tasks for the next development cycle. It can be the task that says to draw up a Communication hierarchy/matrix. It is the morning stand-up or the scrum of scrums. The project manager status update, and coordination documents. Team workflow workshops. It has many terms. But ostensibly it focused not on mowing a “real” piece of work, but rather on preparing for work.

The stagnation

While most technology workers probably have groaned and shuddered reading my list of examples there is nothing inherently negative in those actions. A certain level of “work about work”, from here on out denominated as WAW, is required, everywhere. The challenge is to find the appropriate amount.

And that is where my observation comes in. I have noticed that in the organisations I have worked in or observed the point at which the focus from getting work done, to the focus where WAW becomes the dominant topic filling a team’s weekly or daily tasks (things that they do not necessarily Jira or Trello tasks), Seems to coincide with the point where progress towards the goal of a project halts.

While it is tempting to say (and I have done so myself at times), that the WAW is taking too much time, that is why we can’t get work done. I am now starting to believe it is the other way around. When we for one reason or another are unable to progress a task, we turn to WAW to fill our schedule.

That might come from a well-meaning project manager attempting to solve work inefficiencies, or it might be a subconscious reaction to our inner need to feel and appear busy. I know I haven’t written much on this yet, but suffice it to say, Busyness for busyness's sake, is something I see as the root cause for several issues haunting our industry.

What to do?

So the team lead/scrum master/senior developer has started an initiative to look at your task flow and work processes. Or you have noticed the number of workshops to discuss team performance has increased. Maybe you can’t remember the last time you did something in a relationship like actual work for all the busy work going on. For one reason or another, you see your workday be filled with WAW. What to do?

I posit that it is a symptom of something blocking the progress of the project. Most likely something large. And quite often unfortunately outside of the teams’ control. I claim that when you notice that WAW is unsustainable, start looking at the project as a whole. What is the state of the progress towards your goal? Has the speed at which you are delivering changed, has it stopped? Has the goalpost moved recently, surprisingly it tends to move closer to where you are, not further away.

All of these are indicators that there is a blocker to your project, even if you can’t see an immediate obvious candidate. I dare say, if you see an obvious candidate that likely isn’t it. Anything obvious could be addressed and would not have ground the project to a halt.

Try looking past the obvious, look at all your strands of work, where they stop, and whether is there a common denominator that they are waiting for. Remember you aren’t looking for something easy here. It is likely to be Neblu Luise, and hard to pin down. Likely candidates that I have seen myself:

  • Cultural change in an org (you need the culture to change for your project to progress)

  • Communication between teams

  • Conflicting priorities in an org, or between teams

  • Lack of certain types of resources (outside the team)

  • Murky responsibility matrix (unclear who is responsible for what, and no one wants to deal with it)

Each of these is a topic in and of itself and probably will turn up again and again.

And in most cases, they will be outside of your team’s ability to change or solve. But if you can draw your team’s attention to those blockers, acknowledge them. You stand stronger at trying to bring solutions to those that can fix them. Offer to help if it is resources. Take the initiative to discuss responsibility matrixes (orphan systems are a breeding ground for bugs and problems). Highlight to the higher-ups that there is a conflict in priorities, that is preventing the project completion. Cultural change is the hardest, and I sincerely hope that your project doesn’t depend on cultural change. In that case, close collaboration with the main stakeholders is important. They need to be aware of the blocker, and work should be focused on trying to create cultural change, which is uncertain work in any case.

Is it always an external blocker?

No, Sometimes your work process is bad. Or you are a newly formed team or a large influx of new members, and you need to rally and regroup and find your identity as a team fresh. However, a good team facilitator (a spot of foreshadowing for an upcoming article there) should be able to navigate through that without overwhelming the team with WAW. And as I said in the beginning, a certain appropriate amount of WAW is necessary for every team.

Closing comments

So that was my observation, hypothesis to the underlying mechanism, and an attempt at a soul it ion. Do I believe this is easy, not in a long shot? These are some of the hardest things to see, do, and solve. Especially in the current state of the tech industry. That doesn’t stop me from saying this. In the hope that maybe one or two might take this, recognise themselves in it, and in so doing discover blockers that otherwise would have gone unnoticed and might sink an otherwise great project.

I wish you good luck!

Previous
Previous

Modern Software Engineering (review)

Next
Next

Data Engineering Fundamentals (review)