Losses & Gains, Tracking Task Switching & Thrashing

I take measurements and review statistical data on a range of topics to an extensive degree. However last year, pandemic year 2020, I dug into a few metrics to better tell the story about the damage task switching does to getting deliveries out the door. I wanted to answer one specific question, ideally with a measurable number.

How many projects, tasks, and other deliverables don't get delivered because of task switching via corporate attention deficit hyper-action disorder?

CADHAD

If you've never heard of Corporate Attention Deficition Hyper-Action Disorder, welcome to the latest term I'm going to coin for use in this article. Possibly, I'll use it in future articles, and refer back this one and for that reason let's define CADHAD.

CADHAD - With a silent h this acronym stands for Corporate Attention Hyper-Action Disorder. Being specific, it's the activity, anti-pattern, and syndrome of making activities within a business environment that routinely lead to the completion of other activities getting canceled, forgotten, or outright deleted. Usually after a thorough effort put into these actions being cancelled, forgotten, or deleted and through the switching, or thrashing of effort, extensive costs are spent over effectively having people do nothing.

CADHAD Metrics

Alright, back to answering the question "How many projects, tasks, and other deliverables don't get delivered because of task switching via corporate attention deficit hyper-action disorder?".

Here are a few metrics to get us started.

Actions Assigned, Started & Completed

Projects Assigned, Started & Completed

To note, this is projects assigned to and at least 95% of the tasks assigned during the month for that project being completed equates to the project being marked complete for the month. If it's less than that I leave it marked as incomplete. For example, if I get pulled off of tasks for project A and get put on tasks for project B, and because of that neither all the tasks for A or B get completed, that's 2 projects started or continud for the month and zero finished.

Another important caveat, if a company is efficiently organizing their projects and efficiently utilizing their labor resources - i.e. their programmers - than this would be a 1 to 1 number, anything less than that means there are significant restarts and changes occuring that are significantly damaging effective utilization of people and resources. The TLDR, without a 1 to 1 metric the company is effectively burning cash.

Alright, so here are two sets of data. Let's talk about what each tells us about the story of thrashing. The first part of the year, January through August of 2020 I was at one company - we'll call it "Databases R' Us" and the second part of the year I'll call the company what it is, which is Hasura.

A Story of Thrashing

At Databases R' Us I had joined a team that had numerous projects and tons of actions to get completed. Initially in January was a reset month, and it was, contrary to what the metrics for January tell us, a really productive month. No new projects were started, just preparation by closing up and finished actions or deleting actions. Which even though it doesn't tell us a lot it does show one thing, there were a lot of actions that were entirely dropped. Of the 76 only 11 were wrapped up and completed. The reason, the previous months had left the team with a lot of technical debt that effectively just got ignored and the actions associated with paying that debt just got deleted.

The next month, Feburary starts to paint more of a picture of the significant levels of thrashing that were occurring. New projects were setup and planning had been done, totalling a massive 123 actions and 6 projects. I was ready to go, the team was pumped in that first week. However by the end of the month one can see that the level of thrashing immediately led to a massive failure of projects and actions to be completed. A caveat I have to add, is this is measuring a systemic failure, which is important to note because I could be messing up things myself but as we'll see later I can also deliver robust solutoins when the systemic failures aren't dragging projects and actions into the dustbin of oblivion. February was a rough period of time for the systemic completion of projects and actions that needed done. At month end, a miserable zero projects could be considered to have had their actions completed, and only 11 overall actions were wrapped up.

March rolled in and things improved, thank goodness, I needed the morale boost to be honest! 3 of 6 projects where brought to completion with their respective tasks completed. Bring the actions down to a very reasonable 13 actions to complete led to 11 being completed. An excellent ratio for task completion.

The next four months brough actions and projects into a varied mix of misdirections and failures mixed in with a few successes. Overall the subsequent 4 months Databases R' Us improved efficiency of systemic delivery to about 50% or so. Not good, but much better than the January and February time frame where everything was a vast systemic failure that largely led to teams delivering on things that effectively didn't get delivered to product or customers.

August wrapped up my work with Databases R' Us with final delivery of a project and my departure. A fun time, and a great example of systemic wins and systemic failures around a company delivering or not.

Enter Hasura

I joined Hasura in October, taking a month in September to knock out some of my own personal projects and action activity. As you can see, of the things I planned and started with eventual completion I knocked it out of the park that month. In October, starting with Hasura that streak continued. October had a solid score of 4 projects started, 4 completed and 37 actions started and 29 brought to completed. Not perfect, but really good for just starting out at a new company - when so much time actions linger a bit longer just because one is still setting up their accounts and other requisite but not company useful work toward product or services advancement.

November and December continued that streak, 4 of 4 and 5 of 5 projects respectively. Even though December is often a really dead month for advancement of projects and actions to complete, in 2020 there were a solid bunch that I got into and knocked out. It provided me an excellent win upon new years! Even the actions completion ratio was really good.

Lagniappe Comments

2020 was a strange year, considering the pandemic changes and related characteristics of life itself this year. To compound the intricate complications of 2020 my son was born and I took a chunk of leave in the September and October time frames. Even with this major life event occurring I was still able to - even while taking care of a vast array of baby duties - contribute and knock out work and contribute systemically on a number of level to various projects. So much so, aside from the obvious leave, I'm proud that I went to bat at work at near 100% level even in light of all the pandemic and newborn complexities!

Additionally these were new metrics I had decided to measure and the implications behind them are still a bit hard to describe just from the numbers. Even though it does show the story of the year, it doesn't really dig deep into where and how the task switching - AKA thrashing - occurred or the end result losses from that outcome. Only that it merely happened. This is something where I need to figure out further metrics that could show how, why, where, when, and what occurred that led to these metrics.

At some point I'd love to work on enriching this story through further data collection and figuring out the who, what, where, when, why, and how of the stories the data is meant to tell. Even more so, I'd love to work with others to brainstorm and figure out how to determine what telemetry should be used to provide this richer insight. If you're interested, I'm available via the Twitters @adron and also you can directly mesage me here.

Summary

The wrap up is, the year definitely involved some significant thrashing that led to projects derailed and action items deferred, deleted, or otherwise thrashed on and left as waste. But the year also led to some striking counterbalances to that with 100% of projects getting worked on and delivered, with an excellent ratio of actions getting completed.

References

• Systems Thinking, Measuring Things and Really, Cultural Change is Free and Why Your Measurement are Likely Screwing Up Your Business this is a talk about not measuring, not running metrics, or specifically being careful about measuring the right things and not incurring significant expenses measuring the wrong things that misrepresent the real story behind something. A consideration I always take into account when determining metrics to measure something, and whether I even should be measuring the thing in question.
• Task Scheduling Algorithm for Heterogeneous Real-time Systems Based on Deadline Constraints is a post that isn't related the human task switching, as this post you've just read above is, but it is fascinating how this correlates with human task switching in a similar way.
• Context Switching: Why jumping between tasks is kiling your productivity (and what you can do about it) is a good post. The bar chart midway through the article is excellent for showing graphically much of what is described in my post above.