The Four Types of Work π
A practical framework for organizing product / engineering work.
A few weeks ago I interviewed James Cowling β former Principal Engineer at Dropbox, and we spoke extensively about how to plan software the right way.
The conversation especially focused on uncertainty, and how it should shape the way you design milestones and make decisions.
Later, I published the full write up as a dedicated newsletter edition:
This edition got quite popular and sparked various follow up questions. Two recurring ones were:
β How do you balance roadmap work with unforeseen opportunities / issues?
β Should startups really plan months (years?) of work ahead?
I have opinions on these.
The very first article I ever published on Refactoring covered how we planned work at my startup.
Now, 3 years and 150+ articles later, it is time to revisit it in the light of everything we have learned together (if anything, this was an excuse to redo all the drawings!).
So, 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 for 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.
As I learned later, we were crossing the chasm of different growth stages π
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:
π The Four Types of Work
We figured out that we could divide our activities into four categories, based on two axes: Business vs Maintenance, and Planned vs Unplanned.
This organization proved useful because it allowed us to address different quadrants with different planning cycles:
π’ Business Planned β Quarter OKR
π‘ Business Unplanned β Two-week sprint
π΄ Maintenance Planned β Weekly maintenance
π£ Maintenance Unplanned β ASAP
Letβs look at each of them π
1) π’Β The Strategic Cycle β Quarter 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 OKRs 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.
I wrote more about creating good OKRs and goals in general, in a previous popular article:
2) π‘ The Tactical Cycle β Two-week sprint
This is the regular, two-week sprint cycle that gets things done. It has pretty standard planning, review and retro ceremonies.
It addresses both Business Planned and Business Unplanned activities.
Business Planned β spawned within the Strategic cycle, usually spans multiple sprints, and should be split into independent deliverables that can start and finish within a sprint.
Business Unplanned β is about 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 to commit to a three-month plan without keeping some room for other things. Also, these should have a smaller scope than the Business Planned ones β otherwise it means we kind of messed up the quarter planning.
Even if we routinely call this a sprint, we do not strictly adhere to Scrum: e.g. we donβt do standups, we do release every day, and more. I believe you should actively find what works for you rather than stick to any βstandardβ dev process π
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 on the team.
This cycle was born out of our consistent inability at prioritizing small, impromptu tasks against the rest of the Sprint stuff. 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.
I talked more in detail about this approach (and others) to address maintenance here π
4) π£ ASAP π₯
The only work left out of this schema is ASAP work.
It stands for incidents, hot-fixes and emergencies that cannot wait for weekly operations and have to be addressed immediately.
We also had a simple on-call strategy for this, which I described here π
π°οΈ Allocating time
When we started doing quarterly planning, we thought that for each quarter we should allocate the vast majority of our time to those activities β the Business Planned ones. After all, those were 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.
So, after several quarters, we consolidated our breakdown as follows:
π’ 50% β Business Planned work
π‘ 30% β Business Unplanned work
π΄ 20% β Maintenance Planned work
(ASAP work has always been negligible)
This balance might change for you 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 for today! If you liked this, here are other related articles to learn more:
Also, if you are finding this newsletter valuable, consider doing any of these:
1) π Subscribe to the full versionΒ β if you arenβt already, consider becoming a paid subscriber. You can learn more about theΒ benefits of the paid plan here.
2)Β π»Β Read with your friendsΒ β Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you aΒ great week! βοΈ
Luca
Tα»t. Tuyα»t vα»i.