In a job I had, the entire company used to be managed by individuals, from the lowest through the highest position, who loved to constrain the work environment in a way that SW developers would consume all their time on everything but SW development. They hired highly skilled developers and paid them as such, but they would then overload the developers with non-development tasks. Developers who were determined on keeping sharp their programming skills would eventually need to leave the company.

Every time a developer vented that their calendar was overbooked and presentation slides, spreadsheets and email client had become their only working tools, I used to tell them “It looks like you fell into the metawork pit”. Some people would catch the term really quickly, but others would stare at me with a face like this:

So, what’s metawork then?

Before writing this entry, I googled a bit and found that others were using “metawork” as a term as well. Just like metadata is “data about the data”, metawork is “work about the work”; some said “metawork is anything you need to do in order to do your work”, which is a pretty over-scoped definition. As a developer, your product is useless if not distributed to your customers so, under that subjective definition, one could easily say that “coding is metawork for a developer, since it’s a prerequisite for performing the actual work that matters: deploying the code to production”, which is pretty lame.

When I coined the “metawork” term, I intended a much more specific definition:

Metawork is each worthless task you do at work that’s guaranteed not to improve your product, career and personal growth.

Metawork is garbage, waste, dilapidation, loss.

Let’s consider the next example of a user-story life cycle (for the sake of keeping this post clean, let’s NOT start a discussion of Waterfall vs Agile, this is just for demonstration purposes):

 

 

Can you tell which of the tasks above is metawork? Answer is: None of them, and all of them.

If you paid attention to my definition, you have noticed the “career” part. That means that what’s metawork for some, might not be for others.

For example, for SW developers:

• Analyze is part of their job description and, the more they do this, the better their skills become. Thus, this is not metawork.
• Code is a must. Period.
• Test is on a grey area. For example, if it’s a developer that’s targeting his/her career to become a formal tester, then it’s definitely not metawork. If it’s because the manager is cheap and wants to avoid hiring a tester/QA member, then it’s metawork.
• Deploy is another grey area. For example, does your company have positions specialized in deploying? Do they have a formal deploy process where only some specific people are entitled to deploy (for example, QA Leader or Product Owner)? Are deploys automated? If it’s a task that takes a lot of time and preparation, it might be metawork.
• Support would usually be metawork, since it will only keep consuming the developer’s time. One exception would be if the developer is trying to deal with customers’ interactions as part of their career development plan; another exception would be if the code has an error in production and a bugfix is required.

Now let’s analyze the same example from a QA member perspective:

• Analyze is part of their job description, as they check if incoming changes would break existent requirements, or if the test cases must be updated and such. Not metawork.
• Code is on a grey area, as some testers automate their tasks, which is a good thing, but coding the final product is metawork.
• Test is a must. Period.
• Deploy is on a grey area: Unless only QA members are entitled to deploy after stamping their quality seal on the build, it would be definitely metawork.
• Support would definitely be metawork.

It’s very easy to get lost in the metawork pit. Companies should pay more attention on how the money they invest in developers’ salaries is being used (or any employee whatsoever).

Furthermore, when companies force developers to metawork by doing “all possible tasks of a SW development project”, they are actually serializing all work, all the time, meaning that they are deploying less and less frequently, which seriously damages the time-to-market capabilities of any business.

Other examples of metawork [for a developer] are:

• Making the developers to admin their own servers (especially if there are dozens of them; also seasoned developers are typically more expensive than mid-range sysadmins, for example).
• Requesting developers to justify their own existence (i.e., asking them to create complex business presentations filled with hard data about why they are actually useful to the company and why they shouldn’t be fired, and make that type of presentations one of their weekly deliverables).
• Supporting a business critical operation while also expecting SW projects to be done simultaneously (context-switch will never permit making efficiently neither job).
• Perform each job candidate search, phone screening, interviews, hiring, training and such of each position for the team (specially if a team is contractor-based and contracts expire only few months later, keeping this cycle forever).
• Designate a developer to be also scrum-master/project-manager for a team (being forced to resolve everyone else’s impediments, but also expected to produce code on time).
• Demand the developer to code hundreds of workarounds to overcome to OS/HW limitations, just to save a few bucks of getting newer servers or upgrading some licenses.

 

You also mentioned something about “product” and “personal grow”, right?

Just think about this: each time a person is hired by a company, they are supposed to be hired for a specific position, for an specific team, for an specific purpose; usually, the hiring contract specifies many of these things.

As a developer, you would usually sign the contract and switch to a new job because the product they work on grabbed your attention and because you think it will help you growing in your career and as a person, right? RIGHT?

But that doesn’t mean that anything outside of coding has to be considered metawork. There are plenty of things at work a developer could do to improve the quality of the product, or to become a better person while still doing work-related tasks.

Sometimes, a developer needs to do a couple of things in order to stabilize a project before making big code changes. Remediating part of the tech debt is a typical example of this; for example, a developer might find no source control management system was being used and that all code was being stored in a floppy drive  CD-ROM   DVD   USB stick  cloud folder (ouch, I’m getting old(er)), so he might decide it is required to create a private GitHub repo and upload everything in there, then grant access to the team members, document the “source control check-in process”and train the team on this, before actually doing any new code.

• If you think about this example, the developer is fostering the quality improvement of the final product by enforcing formal source control processes, which allows better handling of code branches, increasing concurrency between developers, sharing code interfaces at sooner stages, easing TDD processes between testers and developers, etc.
• Also, the developer is not keeping this knowledge only to himself, since he is documenting the benefits of this approach, as well as providing training to all the team. He wants everybody to learn about this and help them growing in their careers, thus making him grow as a person.

Who knows, one day someone would refer to that developer as “the only person who actually cared about teaching others in the team” and maybe, maybe one day he will get a nice job offer from one of his former coworkers who appreciated his labor.

That, my dear readers, cannot be metawork. Personal satisfaction it’s part of the work, and it’s part of the fun.