Type I and Type II Work
A breakdown of how work actually works.
As I was writing another article for Jab’s Lab, I realized I was struggling to articulate how work is fundamentally changing under our noses. In order to talk about how AI is changing work, I had to first address the question “What is work?”
I figured for this week’s article, I should put a framework on paper, with the goal of establishing a shared language to talk about different types of work, and set the stage for how AI is primed to disrupt knowledge work. I hope you enjoy.
Work takes a number of forms, but most work falls into one of two buckets: “deciding what work the team should do” and “actually doing it”. I call these buckets Type I work and Type II work.
Type I work is setting a direction. Developing strategy, designing processes, and deciding what the team should work on.
Type II work is the execution. Implementing those strategies, following the established processes, and doing the hands-on work to accomplish the goal.
If Type I is having a blank canvas and deciding what to paint, then Type II is actually painting.
In sales, Type I may look like building the sales methodology and process, developing talk tracks, and deciding on individual reps’ geographic targets. Type II is following the playbook, prospecting customers, and following leads from the established pipeline.
In marketing, Type I may be putting together the brand positioning, and content strategy, and deciding what workflows should be built. Type II is actually writing the blog posts, drafting social media updates, and executing specific campaigns.
In tech, Type I is setting the product direction, and Type II is actually writing the code.
Type I work is creative at its core. Sure, you may be copying strategies that you have seen elsewhere, but really, you’re converting an idea or concept into a concrete reality.
All work has an output, but the key to discerning the work types is the audience of the output. Is your goal to communicate internally (Type I) or is your role to produce something that is to be seen externally (Type II)?
The output of Type II work is something tangible, an artifact that plays a part in the new concrete reality. The output of Type I is typically additional work, along with communication to someone else in the organization of what that work should look like.
The goal of Type I work is to distill a high-level strategy into executable chunks of work (i.e. Type II work). When Type I work is done properly, it is very easy for anyone with the skillset to pick up the task and execute. The goal of Type II work is to actually produce something.
Let’s take the example of a CEO who wants to change the company branding and positioning. They have made a strategic decision (Type I work), and their output is the communication through the proper channels: marketing, design, engineering, sales, all across the board. Each department will take and produce more work, some of which is Type I and some is Type II.
For instance, after the marketing team does the Type I work of researching and documenting competitors and key industry trends, someone is tasked with the Type II work of producing a new positioning statement. Their output is tangible, an artifact of work, and the result of Type II work. A simple decision by the CEO created a lot of work down the organizational chains.
The layers of Type I work to Type II work can be visualized like a tree structure. Each node is a unit of Type I work, and each leaf is Type II work. The goal of every unit of Type I work is to produce Type II work. And the goal of every unit of Type II work is to produce an artifact output.
Often the person doing Type I work does not have the time, skills, or knowledge to fully translate between Type I and Type II. For that reason, the output might be more Type I work.
For example, while a technical Product Manager may know that a new API is required to build a new feature, they may not know the structure of the endpoints or what code is actually required to accomplish this. They may create a Linear or JIRA ticket describing the goal, and an engineer can pick up the task. The Linear ticket is the output of Type I work. And it in itself outlines more work.
Some Linear tickets outline Type I work, and others outline Type II work. The former looks like a vague set of requirements or a product goal that does not have engineering details. The latter looks like a deep technical ticket that has step-by-step instructions for completion. For this reason, the PM produces more Type I work that requires engineering translation to Type II work before being completed.
Type I work is hard, because even if the vision of the final output is perfectly clear to you, you have the curse of knowledge, making it harder to know if you have explained the vision exactly to the next branch in the tree. It’s like playing a game of telephone, where you are sure you communicated it right, but what you said is not what the next person just heard. When in doubt, always add more clarification.
A lot of work is just translating one layer of Type I work to a slightly more detailed and clear version. Adding technical complexity, adding context, and moving the work down the chain. Each layer gets a bit less ambiguous, and a bit more tangible. Eventually, it is tangible enough to actually produce something. An artifact that accomplished part of a goal established at the top layer of decision making.
Most roles have elements of Type I and Type II work, but often there is a clear distinction in your role about what your output is supposed to be. However, there are some Type II workers who like to operate in Type I land. These are the product engineers, the marketing gurus, the sales engineers. They thrive with abstract sets of requirements and do a lot of the Type I work required to set up their own Type II work. Sure it’s harder to do this, but these are the people that remove nodes in the chain. They seem to work more efficiently, because each node causes complexity.
Zooming out a bit, corporate structures exist because each branch in the tree takes time and energy. They are created to optimize the communication between nodes, and shorten the distance of each branch.
However, in upcoming articles, I will be exploring what happens when you shorten the time each branch takes. What if instead of a day, each branch only took an hour, or even a few minutes, or possibly instant? It completely changes what “work” looks like.
I can’t wait to explore the implications of AI on work in upcoming articles. And in the meantime, welcome back to Jab’s Lab.
Until next week,
Cory