Stop Doing Project Management

stop doin the corn

There’s only two kinds of tasks to schedule in your project management issue tracker:

• fast tasks
• slow tasks

if you have other types of tasks, those go in a strategy tracker and not in an issue tracker.

you can follow my system by memorizing a simple acronym GETGUD:

• generate
• enumerate
• tasks
• goals
• uncertainty
• destination

the most important part to remember: your entire project management system/framework/ideology must be understandable and must contain as few steps as possible between idea being logged and final implementation.

if your project management involves 18 rituals across 23 different people each pulling goals and timeframes and priorities in different directions, you have an illusion of project management via process worship, but you’re actually doing nothing at all (nothing at all, nothing at all, nothing at all).

fast tasks

fast tasks are when you know exactly what to do and completion only requires time and focus.

fast tasks are self-contained tasks which don’t sprawl out into other subsystems or other unknowns.

• “add a status button to the user icon”
• “fix typos in the terms and conditions”
• “upgrade the dependencies”
• “fix logging on lines 303-312 to show more useful details”
• “walk to the store”
• “remove pointless 2 second fade transitions between page loads”
• “do 100 pushups before breakfast”
• “stop doin the corn”

fast tasks are often discovered while working on other tasks. fast tasks are a great place to add notes when you don’t want to interrupt your current work to do something unrelated, but you thought up more improvement ideas you don’t want to forget.

slow tasks

slow tasks are when you know an idea and a goal, but you may not know all the details in the middle.

these are potentially sprawling tasks and may involve research or multi-project refactorings or rearchitecture to complete with quality.

• “migrate to async sqlalchemy 2”
• “migrate all services to Python 3.12 and verify no noticeable regressions appear”
• “refactor 5 year old technical debt into a modern project layout”
• “install headscale for our infrastructure”
• “figure out how to build self-replicating robots with a 3D printer”
• “dethrone god”
• “convert the planet to computronium”

tasks should be managed from a Knowledge Discovery Framework (KDF) which is just a fancy word for Trello Columns.

slow tasks will inherently generate multiple fast tasks as you eventually work through the process of discovering the underlying elements of the slow task, but slow tasks are not just “one big idea with 1,000 attached smaller goals.”

A slow task should be two things:

• not 100% known to yourself about how to accomplish it at a detailed implementation level
• yet still have a self-contained end-goal by itself

what makes a task “slow” is your current uncertainty around complete details involving implementation requirements and effort to perform. “slow” means we know it can be done in a bounded timeframe, but we may not know the systems/platforms/APIs/people involved yet. “slow” isn’t “slow because it takes 6 months.”

also, a slow task for you due to your own uncertainty or lack of experience doesn’t mean the task would be a slow task for a different person who may have more experience or who may have done these exact tasks before.

slower than slow tasks

if your tasks are too slow, they aren’t task at all, but entire projects on their own.

If you have a list of “6 month long slow tasks” those aren’t tasks at all. Each of those “slow task” items would just sit unmoving for months. Progress is motion. When a task becomes active, it must be action.

“slower than slow” tasks are entire projects and need their own project board with their own fast/slow task categories.

other tasks

what about the middle? what about having a known goal, but we don’t know if the outcome is possible, so it takes an unknown amount of time and effort?

what about goals which are aspirational or optimistic and you can’t actually sit down and “work on” directly as a single task to completion?

• “increase squat weight by 25%”
• “regrow balding hair”
• “get a life”
• “automate everything then retire”
• “expand revenue 300% by next full moon”
• actually do the corn

those aren’t project management goals. those are strategy goals. this article is not about those. why are you here. what are you doing.

there’s a difference between

• tasks
• strategy
• directed goals
• optimistic goals
• fantasy goals

there’s an old boring MBA-style pointless acronym called SMART which tires to provide a framework for goal setting, but it’s flawed in multiple ways:

• “specific” — having a specific goal assumes you already know what you’re doing. VAGUE GOALS ARE FINE. It’s a process.
• “measurable” — go to hell with your whole “everything must be measured and quantified against everything else and validated and pre-tested and post-tested and in-tested and out-tested” — sometimes you can just do good work then walk away
• “attainable” — wtf? who is setting non-attainable goals? pointless.
• “relevant” — relevant is often taken to mean “relevant to the company/organization” so people aren’t wasting time on “just doing good things” without UNIVERSALLY SIGNIFICANT IMPORTANCE. sometimes you can just do good work without turning every project into an MCU-level event.
• “time-bound” — okay, hyphenate makes this SMARTB, but we can ignore that part. time? You are trying to set a fixed time estimate for something you have not started working on which is back to BDUF/waterfall mindset of “we spend 1 week on planning, then 2 weeks implementing the plan, then 1 week in user review, then launch 1 week later” which WE KNOW DOES NOT WORK. Just the act of doing work is what fleshes out the uncertainty and leads towards workable outcomes. You can’t predict time for all tasks (hence, “fast” known tasks vs. “slow” discoverable tasks).

the more smarter you are, the less you use SMART(B).

Your only goals when task planning are:

• create task as fast or slow
• create EOD / EOW todo lists
• move tasks from fast or slow to EOD / EOW
• if task not done EOD, move to EOW. if task not done EOW, either move to EOM/EOQ/EOY graveyard or put it back in the project list as future priority.

caveats and cravats

one anti-pattern to watch out for is thinking you can explode a single “slow task” into detailed “fast tasks” to the point where a “slow task” looks like just a matter of implementing 5 to 50 individual known sub-components and then it’s done. stop it. bad worker. bad project manager.

your “slow task” is already slow task because it has unknown unknowns inside of it, therefore you cannot enumerate all the sub-tasks and just expect them to be assigned-until-complete!

if your “slow task” has multiple “fast task” components inside of it; you don’t have a “slow task” you have an entire frigging project with its own set of slow and fast tasks which need to be remembered.

be all my tasks remembered

remembered is a key word here.

task management isn’t about “task tracking” or “worker management” or “estimate the story points as dictated by those agile fucks”

task management is about task remembering what the heck to do. have an idea, write it down, get back to it later.

in fact, your task management system should contain duplicate tasks because the goal of a task management system is to get the ideas out of your head and into a more persistent space while you continue working on other things. if you could remember all your tasks and their priority levels, you wouldn’t need a task management system. it’s natural for a task management system to accumulate duplicate tasks because your initial project management goal is to write everything down. Your project management goal is not remember everything you have ever written down and how it all relates to everything else in every present moment until the end of time.

task management systems are about, well, task management. but in our modern world, thousands of companies pervert “task management” into being about “top-down direct control, observation, judgment, and tracking of all employee actions.” Average inexperienced managers will never give up the idea of “all employees are just workers on an assembly line” where the big idea people give people tasks and the tiny worthless workers return to the castle with finished products, then the idea-gods nod disapprovingly at the dirty workers not being good enough, but the non-productive idea-gods continue to give workers more tasks to repeat forever.

adding a task to your project board is a place to dump your ideas presently, but adding a new task must not require integrating your new idea with all the other ideas. if you have 50 tasks on your board, and you want to add a new task, it’s too much of a burden to have to figure out:

• which current task is the new task related to?
• do I add my new ideas as a new task or part of a checklist of an existing task?
• is my new idea actually a duplicate of an existing task?

Though, also, if your project board has grown so big and complicated you can’t actually figure it all out; you are probably cramming too many unrelated projects into one workspace. break it apart already.

Your project board exists for multiple purposes and it’s important not to confuse them:

• quickly adding new ideas to reconcile later
• logging ideas to work on
• selecting ideas to work on
• working on ideas to work on
• recording checkpoint details when working (embedded checklists / details)
• recording task completion / deletion / getting it off the board

When you are adding spontaneous tasks, your only goal is remember this now to revisit later (which is different from N^2 full re-organization and cataloging of your entire task collection every time you want to add one more idea). If you have to read 50 blocks every time you add a new task just to make sure you aren’t duplicating something, your process is failed. Add now, reconcile later.

If your process doesn’t support a fast “dump idea now, reconcile later” workflow, then fix your workflow. protip: fixing your workflow doesn’t mean adding dedicated “project managers” — if your team can’t manage its own goals, your organization has failed.

reconciliation

at some point, tasks have to start getting done. this is where a lot of processes break.

in standard land, you do a thing called “triage” where people sit down, read over all the tasks, then try to argue about the importance of each task and the order of implementation.

this is a waste of time. pure idle busy work.

your careful BDUF/waterfall triage approach will break due to: unexpected customer issues, outages, people out sick, turns out a 30 minute task actually takes 3 days but it’s not important enough for 3 days so other things happen instead, ….

the only order of tasks to be done:

• things causing active problems (unlogged fast tasks)
• fast tasks to improve things
• slow tasks to improve things
• speculative / optimistic / experimental / learning tasks
• wrap-up / finalization / multi-component-integration tasks

logically, you can’t iterate your entire project board todo list in “fast to slow” order because the fast tasks would always block the slow tasks. you’re better off going through and picking off maybe 3 hours of fast tasks then 6 hours of slow tasks then repeating again until perfection has produced a profundity of profitable possibilities.

project management trello layout

• “DO RIGHT NOW BY END OF DAY” (active tasks)
  • this never actually is complete and you’ll have 10 things per day because you’re optimistic, you’ll finish 3 today, then add more tasks the next day; and eventually you have to either stop adding tasks, reprioritize, or declare “immediate task bankruptcy”
  • you can also augment this with another “END OF WEEK” and/or “END OF QUARTER” and/or “END OF YEAR” collection where uncompleted deadline-broken things fall later and later until done or deleted (because if you already broke the deadline and it didn’t matter, the task probably wasn’t important or necessary anyway?).
• “fast tasks”
  • popcorn tasks. things you can finalize in less than 30-60 minutes of uninterrupted focus time.
• “slow tasks”
  • grind tasks. watch-movies-in-the-background-while-working tasks.
  • “slow” doesn’t mean forever though. slow tasks should still take less than half a day of actual focus time, or up to 2 days of interrupting corporate bs time.
  • and remember: the point of slow tasks is often practice, research, and discovery of the actual problem space itself before the real solution work can begin.
• “ideas”
  • just a place for speculation and forward-thinking idea scribbling without even logging anything as a new fast/slow task yet
  • can be used for “nice to haves” like “try out new internal documentation frameworks” or “read changelogs from upgraded dependencies”
  • this also gets into the differences between self-directed personal project boards for your own ideas/growth versus team-wide business-goal-only oriented project boards.

practically, no task-specific goal horizon should go beyond “end of week” (or, even more reasonable “2-day-out”) goals. if your tasks are often more than 2-4 days wide, maybe they are actually part of another project and should be scoped better in a different board. anything further out is unreliable fantasy predictions. the additional EOM/EOQ/EOY lists are for failed EOD/EOW tasks which roll off as unnecessary so they can unblock other more important work in the project.

avoid

avoid task over-specification.

a project management task isn’t an instruction manual or a repair manual. a task is reminders for you to recall what to explore next to solve a problem and implement new capabilities.

difficult, but worth considering: avoid infinite todo lists. If you can accomplish 4 fast tasks per day and 1 slow task, but you are adding 10 new tasks per day, what is your end goal? Within two weeks you’ll just be overwhelmed and give up. At some point you have to stop letting yourself have new long term ideas to chew through the current ideas. If your new ideas are more important than your current ideas, then you need to start down-prioritizing current ideas to let new ideas flourish. If your current ideas are more important than your new ideas, then stop writing down new ideas because it’s just clutter and distraction.

the “infinite todo list” problem is also a classic organizational failure scenario where you have “big idea project managers” creating todo lists but not being productive at the tasks, so they can generate 50 new tasks per week while the actual talented creative professionals doing the work can only get through 3-7 tasks per week as an entire team. Your flow of new ideas cannot be independent from the people working on the ideas themselves because then your organization is failed.

As a last resort, you can create a “complete before EOY” list where you move everything you previously added, but you think isn’t as important anymore, but you don’t want to completely delete yet. Let the cruel march of time approach EOY then on the last day of the year delete everything you obviously didn’t actually need.

extend

you can of course extend task management to absurd degrees.

project management is 9 out of the 12 months in the “how organizations fail through bikeshedding” pinup calendar.

it’s probably also worth pointing out the difference between project management trackers with todo tickets and customer issue trackers with issue tickets.

customer issues aren’t project management issues directly unless the customer problem exposes wider product or organizational failures.

some companies combine both ideas though. Apple’s famous for failing to address almost all customer feedback through RDAR/Feedback systems where customers provide complaints (“feedback” in apple doublespeak) about software, then Apple works on the problems over 5 years, provides no updates, then marks issues as “DONE? PROBABLY? GOOD LUCK, LOSERS.”

i also never understand why people use unchanging, annoying to experience software like “zendesk.” zendesk has always sent out poorly formatted annoying to use emails, yet every company in the world seems to use them. classic case of “the buyer isn’t the user, so who cares?” or, of course what everybody actually hates: king jira. gojira. slayer of logic, implementer of unlimited configurability burden, first of His name, crikey.

many of the popular open source project management frameworks have been shutdown. I personally really liked Trac but it kinda got stuck in 2008 and never updated again (do I still have uncompleted items in my subversion Trac setup from 2006? maybe).

the RT project has also historically been widely used, but nobody cares about running software anymore—it’s the future and people only use software now, nobody runs software— so most places have abandoned it over time in exchange for other various low effort unlimited margin services.

there’s also weird little guys like the djb-disease-analog “never use any software you didn’t write yourself in C and tcl” sqlite guy who wrote an entire revision control and issue tracking system in sqlite, but there have been multiple reports over the years of bugs where it will corrupt your entire development history if looked at the wrong way with no recovery options possible unless you have your own backups.

there’s of course trello and the trello-knockoff github issues view which are great, but also non-portable and you have to give all your ideas to 3rd party companies, but nobody seems to care about corporate security anymore so party on.

i just use free trello for most things and make sure not to put any world-ending ideas there.

conclusion

the goal of project management is to augment the memory of our tiny meat brains with bigger external memory. that’s all. that’s the tweet.

the goal of project management is to remember good ideas then work on good ideas.

project management is about having ideas, moving ideas around in a rewarding implementation order¹, then implementing ideas.

people often confuse project management with “authoritarian business people control” where society has created a special class of “project managers,” who don’t work on products themselves, but somehow obtain the (attempted) power to direct actually talented people in what to do and when to complete and then managers complain final results don’t match some poorly generated unchecked plans up front.

long-term up-front multi-step plans do not work. we know this. we know dis. BDUF/waterfall feels great during planning and awful during execution. Too much up-front planning leads to dead projects and dead companies all over the place. The project must flow through you with trust and accommodation, not pharaoh-esque “so let it be written, so let it be done.”

you can’t know a full plan up front unless you have perfect knowledge of the future, so the only way to build things is by looping incremental explore-build-test-verify-reëvaluate-realign cycles.

in summary:

• list tasks to do
• use your judgment and do tasks in a good priority order
• everything else is just a control fantasy

---

1. Note: the order of tasks isn’t supposed to be the BEST order or even MOST IMPORTANT order. It often makes sense to work on small useful things first before jumping into bigger “MAJOR BUSINESS PRIORITY” tasks needing two days of abandon-me focus time. If you waste time arguing “is this task worth 6 effort bananas or 7 effort bananas” for 20 minutes instead of just doing the 30 minute task yourself, what happened in your life?↩