Innovation requires a combination of work and meta-work. By “work” I mean doing things that tangibly impact your product; designing, coding, marketing, etc.. “Meta-work,” in contrast, involves improving how you’re working. This often looks like meetings to synchronize the activities between teams or applying frameworks like OKRs or lean startup.
Over-emphasizing work, while neglecting meta-work, turns you into a feature factory where you’re producing in high quantity, but the stuff you’re making is of questionable value.
Conversely, spending too much time on meta-work often entails a day full of meetings and bureaucratic processes when no work is actually done. Large companies have no choice but to spend lots of time on meta-work since they need to coordinate the work of many specialized contributors. They must maintain safeguards to prevent the loss of market share already won. This in part explains why big companies are so prone to get disrupted — they don’t have time to actually work.
Growth stage companies, however, are in the predicament of having to consciously decide how to balance work and meta-work.
Relentlessly working without pausing to reflect and communicate might succeed with a small team of founders, but it doesn’t scale to new employees and multi-team orgs. Meta-work is required to prioritize the work necessary for solving future problems that can’t be felt viscerally at the present moment.
But speed matters too. If you don’t “move fast and break things,” it’s harder to sneak up and capture a new market or catch an incumbent player flat-footed.
The tension between work and meta-work, in part, is why we’re seeing a rise of tools focused on meta-work. While there are tons of tools for getting work done, project management tools, dev tools, design tools, etc., there are fewer tools that change how we work. Now we’re seeing a growing market of product management tools that help teams communicate roadmaps or track their progress against OKRs. My project, Double-Loop, helps teams learn and communicate by recording a timeline of hypotheses and results. This is faster than the meta-work task of sending a product launch email or slides.
These tools remove the tension between work and meta-work by making the meta-work more efficient. If you can spend less time getting the benefits of meta-work, you have more time for the actual work. You can optimize for speed and value.
Stand-up bots, like geekbot, are the most literal version of this. Instead of spending the time on synchronous meetings to synchronize, you can synchronize asynchronously; fewer people have to break their flow to attend an in-person meeting. Slack is powerful because it’s a tool for completing the necessities of work with meta-work automation mixed in.
Automating meta-work is a little bit like automating the role of the manager. It’s the manager’s job to preserve team harmony, create accountability, and set strategy. Meta-work tools allow teams to do this bottom-up.
However, elements of meta-work resist automation. As the head of product for a growth stage company, just because I ask my team to use meta-work tools doesn’t mean they actually will. It’s hard to prioritize meta-work tools that can feel like distractions from pressing tasks.
I discovered that meta-work tools, ironically, require meetings to drive usage. I can ask my team to use our new OKR tool, Gtmhub, but no one would use it if we didn’t have a meeting to review the data we enter into the tool. Similarly, my team wasn’t using Double-Loop until we structured meetings around looking at Double-Loop to look at product launches and results.
The designers of meta-work tools should prioritize making screens that are specifically suited to be projected on the wall during meetings. Meetings are the lifeblood of these tools. It’s not the job of meta-work tools to completely kill meetings. However, it is their job to make meetings less frequent and more efficient.
The best meta-work tools minimize duplicate data entry. Meetings are especially costly if you need to spend an hour updating a spreadsheet before the meeting. As much as possible, the data in meta-work tools should be aggregated from the actual work tools.
In Double-Loop, we’re building a timeline of product launches that can be understood outside of the tech team, yet the building blocks of each launch event come from Jira. The team still needs to add new information for context, but I believe the Jira bootstrapping will be key to driving adoption.
Teams, in general, are getting more thoughtful about designing their toolchains, and companies like Segment, Zapier, and Unito make this easier. To take this one step further, I believe companies need to think beyond tools chains and design meeting+tool-chains optimized release the tension between work and meta-work.