What My 2024 Productivity Stack Was Trying to Fix

What My 2024 Productivity Stack Was Actually Trying to Fix

My productivity stack in September 2024 was an attempt to protect focused contribution without solving every collision by working later. Todoist, calendars, ClickUp, and several named methods were implementations. The real problem was that meetings and ad hoc requests kept breaking the time I needed for coding, research, and other sustained work.

The episode captured a system in motion. I had only used time blocking for about a week and a half, and I said plainly that the setup might look different a year later.

flowchart LR
    A["Commitments from work and life"] --> B["Personal capture and clarification"]
    B --> C["Task list"]
    B --> D["Calendar commitments"]
    B --> E["Shared project record"]
    C --> F["Daily and weekly review"]
    D --> G["Protected focus block"]
    E --> H["Team status and dependencies"]
    F --> G

The stack began with fragmented attention

E032 opened with a familiar limit. Work, family, relationships, friends, exercise, learning, travel, and personal projects all compete for finite time.

At work, the sharper problem was fragmentation. A two-hour opening could become several small gaps after an unexpected call and another meeting. Each transition carried follow-up, note-taking, food, water, and the effort of remembering where the original task had stopped.

I had responded by working later. That protected some individual contribution while taking time from exercise and life outside work. I did not want the productivity system to become a justification for a longer day.

Todoist became the private task layer

I chose Todoist over TickTick largely because its interface felt consistent across my Windows computer, MacBook, Android phone, and the web. That was a personal preference, not a general ranking.

I used a quick inbox or brain dump, then separated work, personal life, Venture Step, travel, learning, dates, and other areas. I wanted recommendations and ideas to become actionable or leave the active system. I also liked ending with an empty inbox and a small completed-task animation.

That approach had a risk. A clean interface can reward clearing what is visible rather than completing what matters. Inbox zero and task zero are useful maintenance states only if important commitments remain represented.

The current GTD definition describes capture, clarification, organization, reflection, and engagement. My setup borrowed from those ideas, but it was not a claim of formal GTD practice.

The calendar became a commitment layer

I connected tasks and calendars so meetings, personal events, and planned focus could be seen together. The goal was not to schedule every thought. It was to see whether the day had room for the work I was promising.

Current Todoist calendar documentation is materially different from the source-era description. It now documents Google and Outlook connections, read-only event display, task-to-event syncing, plan-specific calendar layout, permission requirements, recurrence limits, and deletion behavior.

That is why the episode's exact sync path should remain historical. A calendar integration is also a data and policy decision. Work accounts may restrict it, subscribed calendars may expose details, and a public URL carries a different access boundary than a private invitation.

Time blocking was a boundary, not a miracle

I started placing focus time on the calendar because unclaimed time kept being treated as available. The block was meant to protect coding and other high-value individual work while leaving room for the meetings my role required.

The useful part was making the tradeoff visible. A day cannot hold six hours of meetings, three hours of focused work, ordinary administration, and infinite interruptions without something moving.

The episode was too early to establish that time blocking had improved my output. I said it felt helpful. I did not measure completion, quality, interruption frequency, or what got displaced.

The stronger method is [[How to Use Time Blocking for Deep Work]], which includes an outcome, preparation, interruption rule, shutdown note, and recovery slot.

I combined methods by situation

I used Eat the Frog for work I was avoiding, a longer version of Pomodoro for starting resisted tasks, the Eisenhower matrix for priority, time blocking for deep work, and day theming for longer-term initiatives.

That mix was practical, but it also risked turning every task into a small ceremony.

The official Pomodoro Technique site describes planning tasks, estimating effort, handling interruptions, and recording completed intervals. My 45-minute variation was a personal adaptation. The timer was useful only when it helped start or sustain the work.

The durable rule is to give each method one decision job. If two frameworks both prioritize the same backlog or schedule the same day, the system is paying twice.

A private priority system accidentally became public

One of the most useful mistakes in E032 came from an earlier workplace. I had used an Eisenhower matrix in Asana and later realized colleagues could see labels that marked their requests as not important.

Nobody raised the issue with me. That did not make the design appropriate.

A personal ranking may contain private scaffolding, incomplete thoughts, or language that is efficient for the individual and harmful without context. The team still needs a shared priority, owner, due date, dependency, and status. Those are different records.

That experience became [[Personal Tasks and Team Project Management Are Different Systems]].

ClickUp represented shared project truth

I preferred ClickUp among several shared project tools because its hierarchy made sense for departments, projects, tasks, and rollups. I compared it with Asana, Monday, Wrike, and Notion, often in blunt personal language.

Current ClickUp help documents Workspace, Space, Folder, List, task, and subtask layers and notes that access can vary by location. Its hierarchy guidance maps different project sizes to different structures and views.

Those pages support current discovery. They do not prove that ClickUp is the right product for a team or that my 2024 price and feature comparisons remain accurate.

Subscription value needed a better test

I argued that a paid time-management tool could be worthwhile if it saved meaningful time. That instinct was reasonable. The episode's hypothetical savings were not evidence.

A subscription adds setup, integration, maintenance, migration, renewal, privacy, and exit costs. It can also deliver quality, calm, reliability, or accessibility benefits that do not fit a simplistic hourly calculation.

The right response is a bounded trial with a baseline, real work, an export test, and written buy or cancel criteria. [[How to Decide Whether a Productivity Subscription Is Worth It]] turns that idea into a method.

What E032 actually established

E032 established that my old arrangement was not protecting enough focused work. I responded by separating personal capture, calendar commitments, shared projects, and situational work methods.

It did not prove that Todoist, TickTick, ClickUp, Sunsama, GTD, Pomodoro, time blocking, day theming, or the Eisenhower matrix improves productivity for everyone. It did not validate source-era prices, current integrations, workplace approval, or privacy.

The enduring question is simpler: does the system help a person keep commitments, make tradeoffs visible, protect valuable work, and recover when the day changes without becoming another job?

Watch the preserved E032 YouTube recording. Continue with [[How to Build a Personal Task Management System]] for the workflow or [[How to Use Time Blocking for Deep Work]] for the focus method. Readers interested in the next episode's move from repeatable work to reusable AI instructions can continue with [[What Building Curio and the Venture Episode Engine Actually Taught Me]].

This story was developed with AI assistance from the immutable Google Drive transcript, the preserved YouTube caption source, current first-party product and method records, and the linked historical research record. Dalton Anderson remains the author. Transcript, product, workplace, privacy, commercial, current-source, and founder review are mandatory before publication. Publication is not authorized.