I frequently find myself in a cycle where I’m switching between phases of “Feature Work” and “Maintenance Work”. Sometimes the cycle is morning-to-afternoon, sometimes weekstart-to-weekend, sometimes week-to-week, sometimes month-to-month. I don’t think this is unique so much as I have noticed that these two different phases require different mindsets —an almost entirely different brain— and have different outcomes and rewards systems. I’ve tried to sum it up in this in a table.

Feature Work Maintenance Work
Speed Slower Faster
Scope Large-scale greenfield work Isolated changes
Depth Mostly deep work Mostly shallow tasks
Quantity Massive number of big changes and cascading issues Many small changes
Autonomy Low, many stakeholders High, few stakeholders
Risk High risk, going over budget, feature cancelled Low risk, but problem can be much more difficult than expected
Reward Looks good on résumés, product announcements Not glamorous, barely a footnote
Timeframe Weeks/Months Hours/Days
Testing Validation with people, broad Step-by-step reproductions, targeted
Organizational influence Big splash, turns heads, firm handshakes Overlooked, under-celebrated
Mental requirements Big brain to solve large puzzles Robot brain to mechanically power thru

This maps with Cal Newport’s concept of “Deep Work” but feels distinctly different to me. Writing a blog post (deep work) and checking my email (shallow work) share some brain space similarities with a homepage redesign (feature work) and robotically powering through dozens of UI nudges (maintenance work) but are different a product or organizational context. The timescales, risks, and social rewards add another dimension to the work modalities. The Feature work → Maintenance work loop is also about balancing the growth and health of a product with a cycle of building and repairing which goes way beyond crossing items off your peronal todo list.

I heard this called “Tick-Tock” in a meeting, which I believe is a reference to Intel’s chip release cycle: microarchitecture changes (tock) followed by a die shrink (tick). In the context I heard it, “Tick-Tock” described the “Expanding” then “Stabilizing” phases of design systems work, which I think applies in spirit. Notably, Intel moved away from Tick-Tock and added an optimization phase to extend the lifespan of each generation of chip. That’s probably a whole other blog post about how we could introduce an optimization phase to our worklives to extend our personal lifespan at work.

You see the Feature work → Maintenance work occurring elsewhere in nature; like Linux and Node. Those projects have this cycle built into their version numbering; odd numbers are “development” branches (don’t use those) and even numbers are “stable” branches (use those). Expanding and stabilizing. Apple used this loop a bit with OS X releases where Leopard was the feature release and Snow Leopard was the maintenance release. It had an interesting user effect where I was happy one year with new shiny toys and I was happy the next year when all the apps on my computer got better. They embraced the cycle effectively (and made headlines).

Do you do this? Do you do it differently? I personally refer to maintenance work as “nudge work” because that’s what it feels like, like I’m nudging buttons on a page until they’re perfect. And greenfield feature work is always more refreshing after a season of unseen mechanical nudge work. What do you call it? I’m interested in this concept of phased product work so I’d love to hear more about how others think about this.