Scale yourself with the "metawork mutual fund”

Banner image of woman at work

Summary

“Metawork” is all the work we do, to make actual work happen. On software teams, that actual work includes writing code, designing interfaces, testing functionality and deploying applications.

  1. If you want to do something new, you must make yourself redundant in your current role. For that you must make your metawork explicit.

  2. Making metawork explicit is like investing. It’ll work for you even when you are not present, just like how the invested money will earn you more money while you sleep.

  3. When a team, department or company makes their metawork explicit, the collective builds resilience. You create a metawork mutual fund.

  4. To scale yourself as a leader beyond the physical limits of time and personal energy, invest in making your metawork explicit.

When I joined Thoughtworks in 2007, I realised how different the company was to the two other IT jobs I’d had before. Particularly striking was how many of my senior colleagues approached projects. 

“My goal when I join a project is to become redundant, eventually.”

For some time, my conditioned brain couldn’t compute this. Why would someone want to be redundant? As I dug into this more, I realised that my tenured colleagues were aiming for a couple of benefits.

  1. If they became redundant on their projects, it represented their success in a way.

    • Either the processes on the team were strong enough that they didn’t need a specific role any more.

    • Or someone had grown to take up the senior colleague’s role.

    • Or both!

  2. Once they became redundant on one project, they could work on another and learn something new.

In a professional services environment, this made perfect sense to me. Of course, if you want to learn and grow, you’d like to work on a variety of projects. But if you’re indispensable to your current project, how will you move to another one? Hold that thought.

In 2007, Thoughtworks was a 14-year-old company. You’d think that was enough time for a company to become big and established. We were still a tiny operation though. We had 80 odd people in India and all the trappings of an upstart. As a privately owned company, we all looked up to Roy, our founder - a tech maverick with subcontinental roots. Martin Fowler has described Thoughtworks as Roy’s social experiment - an idea many of us old-timers still hold on to. Roy clearly had the knack of grabbing your attention. My colleague and long-time Thoughtworker, Mikey Aguilar, would tell stories about Roy’s hiring messages for example. 

  • “We suck less”

  • “The best consultancy you’ll ever hate”

  • “The art of heavy lifting”

There’s a word I heard Roy say many times in my years working for him. “Metacognition”. It’s a fascinating idea - thinking about your own thoughts and learning. No wonder he named the company Thoughtworks. 

 A few days back, this term came back to me. You could say I was being meta-metacognitive! That’s when I also started thinking about how one makes themselves redundant. And a term occurred to me - “metawork”. Here’s how I define it.

“Metawork is all the work you do, to make your actual work happen.”

For example, in software engineering, the actual work is writing code, designing interfaces, crafting copy, deploying applications or testing functionality. Most other work is “metawork”. Its function is to enable actual work. 

Let’s come back to that question about making yourself redundant on a project. For engineers, designers and testers to do their work, usually some “leader” must do the metawork. To a certain extent you can use engineers, designers and testers interchangeably. It’s people in lead roles who seem indispensable. The metawork they do, sits in their heads. Unless they make this metawork explicit, it’s tough to become redundant.

I’ve been thinking about this concept of metawork in relation to async-first organisations. Admittedly, it’s still a work in progress, but I want to put it out there while the ideas are still fresh in my head. Let me explain this further.

Work that works when you’re sleeping

Think about why you invest your money in equities. The idea is simple. You have some money. You’d like that money to earn you some more money. It’s a passive act in a way. Invest the money in the right place for long enough, and you’ll earn money while you sleep.

In a similar way, if you want to make yourself redundant, you must make your metawork explicit. Your work should work even when you sleep. Let me share a few examples of explicit metawork.

  1. Decision records. Decisions allow you to progress your work. Record them and create an audit trail. You can reference them later by just “responding with a link”. Your metawork works for you.

  2. Automation. Is there a repetitive task you perform that a rule-based system could do instead? Automate it. Even if you can’t code, there’s so much you can do by just wiring together spreadsheets and survey forms.

  3. Frameworks and templates. Is there work you do that you can simplify for others? Create a framework or template. Test engineers do this all the time, by creating automation frameworks for their teams. You’ll notice that I’ve done something similar on this site by sharing retrospective templates with you. You can use these to run your own retros, much like I’d run them for my teams.

  4. Online learning. Many of us have picked up skills from our experience that we can teach others in a short time. The trouble is, that if you try doing this real-time, you become a bottleneck. How about putting those learning materials online? They needn’t be fancy. Back in the day, Richa Trivedi and I realised that many analysts applying to Thoughtworks, could do with a basic introduction to agile analysis, so they have a fair chance in the interview process. So we created a playlist on YouTube, called Foundations of agile analysis. Similarly, I noticed that estimation is a thorny and confusing topic, so my colleague Akshay Dhavle and I created the Estimation and planning masterclass. Now you don’t need Richa, Akshay or me anymore. Just watch the videos!

  5. Knowledge sharing. Like with skills, sometimes the only difference between us and another person is the knowledge we have. While we may have spent years getting to that piece of knowledge, others don’t have to. We can make it simple for everyone else by just writing things up! This is the easiest way to make metawork explicit. This website is my attempt to do just that. 

Here are a few questions to ask yourself when you’re doing any metawork.

  • How can I take myself out of the equation, the next time this metawork must happen?

  • What’s the most scalable, lightweight way to teach someone how to do this metawork?

  • Is there something I can do, so no one has to do this metawork anymore?

Efficient distributed organisations are metawork mutual funds

To stretch the investment metaphor further, let me invoke the idea of mutual funds. With mutual funds we pool in money from various investors. This gives the fund manager access to more funds and the flexibility that comes with it. Investors get the benefits that come with scale - lower trading costs and shared risks. Fabulous!

Screenshot of GitLab's handbook

GitLab’s handbook is their metawork mutual fund

I notice that efficient async-first organisations apply a mutual fund approach to their metawork. GitLab is a notable example. Everything they do is part of their handbook. You’ll notice that they work hard to ensure no one’s indispensable. Of course, this’ll always be a work in progress, but that’s in the spirit of their value of iteration. Everyone contributes to this collective body of knowledge. This is a “metawork mutual fund” in action. When an entire team, department, or company makes their metawork explicit this way, it pays dividends not just for the individual but the collective as well.

If you aspire to be a leader in your field, your biggest challenge is to scale yourself. There are two ways to scale. One is the linear model, where your impact is directly proportional to the time you spend working. This model has its human limits. You only have a forty-hour work week, or if you’re lucky, a four-day work week. You could overwork, but there are limits to how much a tired mind and body can achieve.  

The alternative is to adopt a non-linear model. Here you invest effort in making your metawork explicit. If you do this right, your work will work for you and you’ll scale yourself beyond your physical limitations. What if all your colleagues could work this way? Wouldn’t that be amazing? Wouldn’t that free us all up for new challenges and new learning?


I started this article with the notion of “redundancy”. If that word makes us uncomfortable, especially in this recessionary climate, I understand. I’ll be the first to admit my insecurity with that word. Conversely, I know that until I make myself redundant, I can’t do something new at work. If I keep doing what I’ve always done, I’ll learn nothing new. Becoming redundant may well be a path to growth, especially for a consultant like me.

In fact, I’m also applying the concept of explicit metawork to the talks I do. I recently did a talk for a bunch of technologists in China. The next time I speak, I want to do something different. So I’ve recorded the talk as a playlist of online videos. Three videos; 13 minutes, 40 seconds. If you’re in the audience, the next time I speak, you’ll hear a new message. A part of me is now redundant.

Previous
Previous

No, that’s not culture

Next
Next

You don't need Slack. You need slack.