What is your constraint? Mine is anti-work

We, as engineers, not only are worried about creating new things, we need to be able to detect the cause of future issues. However, we must not limit ourselves to software, but to the entire software development team organization.

How it all started: The Phoenix Project

I was reading the other day the book “The Phoenix Project”, and while the book is a good read, I was geting bored. I was having the feeling that I was reading a kind of diary of an IT person, whose experiences resonated with mine, but to be fair nothing else nothing more. An outage here, the IT infrastructure being a dumpster fire, software that is not tested at all, violent communication between teams, bad leadership, etc. To sum up nothing that in my 15 years of work I had not already experienced suffered: the human condition.

However, a conversation between the main character (Bill) and Erik (a board candidate) was particularly interesting and caught my focus: Erik was asking Bill for their constraints, understanding constraints as the bottlenecks defined by Goldratt in his Theory of constraints.

That made me thing: what are my constraints?, or even better what are my team constraints? In the case of Bill, it was a member of his team that was the one that fixed all the issues (fires) that were popping up.

What are my constraints?

I am not a manager, nor a team lead, but an IC (individual contributor), so this kept me thinking about, what were the constraints on my reach?

Most of the time is the issues, fires, unregulated requests, support, a DM from a developer that asks you something and you need to answer… In other words anti-work. Exactly that term was the one used by Erik in the book, and I think it approximates pretty well to what actually is.

This kind of work fights for our time with the actual work we have planned to do. Indeed, if we do not limit the anti-work, it can use all the available time and expand out there even.

As it is a chaotic force, the anti-works needs to be tamed, reduced, and ultimately removed. But how?

How to remove anti-work

By removing the sources of it. i.e. not allowing unregulated work unless it is affecting to the capacity of the organization (usually clients, customers, or users).

The first reaction of the employees that are sources of anti-work would be disbelief, and later they feel hopeless, and maybe even angry! But our job would be to show them the proper workflows for requesting support, new features, and raising issues.

If there are no flows for managing requests, that is the first thing to do. Not relying on DMs, creating good documentation to reduce unknown corners, enabling web forms, using a support channel that is answered from time to time, or even creating chat-bots that by using AI could help users, are good solutions.

Interruptions are mind-killers so you need to make sure the requests can be added to a queue and stay there until you have finished your mental task, has left the software development mindstate, and has entered software support one.

Conclusion

Have some priorities in your day to day. You cannot work in everything. Issues/unregulated requests/petitions/suggestions/new tasks should be added at the end of the queue.