The Four Types of Work 🗂

A practical framework for organizing product / engineering work.

Luca Rossi

and

Nicola Ballotta

Nov 07, 2024

∙ Paid

I have been writing engineering newsletters—Refactoring first, and now Hybrid Hacker—for more than four years now.

During this time I published more than 250 articles. This is an insane amount of words: if you do the math, it’s like the whole Harry Potter saga — just with less magic (and less sales).

I feel grateful to have never lost the desire to do research and write new things, but these days I also like to go back to articles I have written in the past, to polish them, improve them, and use them as inspiration.

In a way, it’s like chatting with a previous version of myself.

The very first article I ever published talked about how we planned work at my startup. Today I am revisiting it in the light of everything I have learned during these last years (and, if anything, this was an excuse to redo all the drawings!).

Here is what we will cover today:

🎯 Setting goals in a startup — what’s your goal about… goals?
🍀 Four types of work — a simple framework that splits work into business vs maintenance, and planned vs unplanned.
🕰️ Allocating time — how to make ends meet.
📚 Resources — stories and further readings to learn more.

Let’s dive in!

There was a time, a few years ago, where I often asked myself: what would Erik do?

Many people grow up with mentors over their careers. The funny thing is that, after talking with them for a long time, you build some kind of mental model of these people in your head.

You get to the point where you can have imaginary conversations with them, with—I believe—pretty realistic results.

It feels weird now that mine was a fictional character from a book. I guess it was fine.

⚔️ The Jedi Master

Erik Reid acts as a sort of Jedi Master in The Phoenix Project — a book that teaches the ways of DevOps by means of a fictional novel.

The book is so engaging and memorable, that I always wondered why we don't have more business novels written this way. I suspect because most authors don't have the skills for that — they simply wouldn't be able to pull it off.

Erik explains some of the key ideas that drive the story forward, like The Three Ways, and in particular The Four Types of Work, that inspired part of this post. These are frameworks about the nature of IT work, and they help Bill — the main character — improve processes within his org.

At the time, I remember not being able to apply these principles verbatim to my own reality — that of a small startup. I understood the rationale behind the framework but couldn’t find a way to make it useful to us, or shape a process around it.

So, over time, we developed our own version.

🎽 The Team

For a few years, we worked as a team of ~20 people. As an e-commerce company with a website and two apps (iOS + Android), about 3/4 of the team was about product & engineering.

20 people is that awkward size where the informal way of managing things begins to collapse, but folks are still too few to be split into independent groups. You still have singletons here and there—positions covered by a single guy—and most people need to rotate across multiple projects.

At the same time, though, negotiating resources for projects becomes non-trivial, as there are multiple areas that deserve your attention.

So, we progressively changed our way of managing goals and activities. We figured this out through trial and error, and we eventually ended up with something we were happy with.

🎯 What's your goal about… goals?

I wrote several times about creating good goals, e.g. with OKRs.

However, before you choose this or that planning method, you should ask yourself what you want to achieve with this process. In my experience, if you are a small, tight-knit team, here is what you should aim for:

🗺️ Alignment — everyone needs to know the company goals and the roadmap to accomplish them. This kind of visibility creates momentum and allows people to take initiative.
🚲 Agility — your planning should enable long, ambitious projects, while also retaining the agility of tackling smaller activities within a short notice.
🍻 Participation — everyone should be able to submit ideas and join the conversation in some capacity.

For years, as long as we were 10 people or less, all of this felt easy.

But scaling the team, even modestly, kind of broke how communication happened, and things stopped working like they used to. Like many things in life, it didn’t happen all of a sudden — even though it seemed so in retrospective — it was a slow change, and hard to detect. But the consequences were very real: productivity decreased, deadlines were often missed, and more than a few people left.

You may be tempted to think that when a team grows it is naturally bound to lose some efficiency. While this is true to some extent, for the most part it’s just that what got you here won’t get you there, and you need to tweak things.

As a leader, a lot of your role as your team scales is about closing that productivity gap 👇

So, after a lot of experimentation, here is what we came up with: