The Four Types of Work 🍀

A practical framework for planning Product & Engineering work.

Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

---

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

Many people, over their career, grow up with mentors. After reading / talking with mentors for a while, you end up with a mental model of these people. You can get to the point of having imaginary conversations with them, with — I believe — even 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 business authors don't have the skills to do that — they simply wouldn't be able to pull it off.

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

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 for us, and shape a process around it.

So, over time, we kind of developed our own version.

The Team

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

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

At the same time, though, you are expected to be able to sustain work on multiple areas, and negotiating which resources should be allocated on which projects is often non-trivial.

During this stage, we progressively changed our way of managing goals and activities. It took a lot of time to figure this out, mostly through trial and error, but we ended up with something everyone was happy with.

What's your goal about...goals?

When it comes to organization, each company is different, but I believe some challenges are pretty common. In our case:

• We wanted everyone to be on the same page about the company goals and the roadmap to accomplish them.

• We wanted to be rigorous enough to develop long, ambitious projects, while retaining the agility of tackling smaller activities within a short notice.

• We wanted to make sure we didn't neglect any particular area, and that requests for improvements could be submitted by anyone in the team and scheduled properly.

For years, as long as we were 10 people or less, all of this felt easy. We just relied on a bi-weekly planning cycle (Sprint), with a simple high level roadmap on top of that. We applied a standard Scrum process and everything went fine.

But scaling the team, even modestly, vastly changed how communication happened, and things just didn't work like they used to. Like many things in life, it didn't happen all of a sudden — even though it may seem so in retrospective — it was a slow change, one that was even hard to detect. But the consequences were very real: productivity decreased, deadlines were often missed, and more than a few people left.

We 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, I believe that for the most part we just have to realize that what got us here won't get us there, and adjust accordingly.

Business vs Maintenance — Planned vs Unplanned

In our case, we came to the realization that we could divide our activities into four categories, based on two axes:

• Business vs Maintenance

• Planned vs Unplanned

To be fair, there are several other ways of dividing activities into “buckets” — based on priority, area, size, and so forth. This particular one stuck because it was actually useful.

The usefulness comes from the fact that the different categories can be addressed by different planning cycles. This way, the act of defining which category an activity belongs to is a major step towards planning it correctly.

Based on these, we organized our work into three (+1) cycles:

• Strategic Cycle (OKR)

• Tactical Cycle (Sprint)

• Operational Cycle (Maintenance)

• ASAP

☝️A visual representation of cycles and types of activities. Clearly, my drawing props can be improved.

1. The Strategic Cycle – OKR

This is the big one, which for us meant the quarter planning. Business Planned activities are those crucial to match company KPIs — they are thought out well in advance, and everybody knows them.

We used the OKR framework to model them. We typically built a tree that went from high level company goals, down to metrics and activities that we believed would accomplish them.

2. The Tactical Cycle – Sprint

This is the regular, two-weeks sprint cycle that gets things done. It has planning, review and retrospective ceremonies that I will not discuss in detail as they are pretty standard.

It addresses Business Planned and Business Unplanned activities.

Business Planned activities, spawned within the Strategic cycle, usually span multiple sprints, and should be split into independent deliverables that can start and finish within a Sprint.

Business Unplanned activities are opportunities we didn't anticipate in the OKR, but are worth doing anyway. That's the agility I mentioned in our challenges: as a startup, we cannot afford committing to a three months plan without keeping some room for other things. Also, they have usually smaller scope than the Business Planned ones — otherwise it means we kind of messed up the quarter planning.

3. The Operational Cycle – Maintenance

This has been our last addition. It is a short, weekly cycle that has a fixed time allocation (20% of the overall time) to address bug fixes and small changes requested by anyone in the team.

This cycle was born out of our consistent inability at prioritizing small, impromptu tasks against the regular Sprint activities. At some point we figured out that the only way to make progress on those was to allocate a fixed time for them every week. We call this work Maintenance Planned and includes anything from bugs to small UI changes requested by a PM, to back-office work that may be needed by the Customer Success team.

ASAP 🔥

The only work left out of this schema is the ASAP work. It stands for incidents, hot-fixes and emergencies that cannot wait for the weekly operations and have to be addressed immediately.

Allocating time

When we started doing quarterly planning, we thought that for each quarter we should allocate the vast majority of the time of our team on those activities — the Business Planned ones. After all, those where the most valuable things we could come up with.

We made estimates and set goals based on the rough assumption of spending 70-75% of our time on them. The reality is we never reached those numbers, as unplanned work always kicked in moving or canceling some of the goals.

☝️Our final breakdown between types of activities

After several quarters, we consolidated our breakdown as follows:

• 50% — Business Planned work

• 30% — Business Unplanned work

• 20% — Maintenance Planned work

The Maintenance Unplanned work (ASAP) has always been negligible.

I believe this breakdown might change based on several factors, such as company size, industry, and more. Each company should find its own, I just think it's important to put yourself in the mindset that 1) there will be unplanned work, and 2) it will probably be non negligible.

It's also important to understand that unplanned work is not a bad thing. If you find you have very little of it, it is probably because you are not looking hard enough. In the life of a startup there are plenty of opportunities that arise unexpectedly, and cannot wait for the next quarter to be addressed.

And that’s it! What’s your experience with planning work? Let me know what you think in the comments 👇 or via email.

---

Hey, I am Luca 👋 thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Friday and put your own growth on autopilot!