Functional Teams with Executive Dysfunction
The open source project I've been working with has been struggling with project management recently. In a project with such a broad scope, how can we encourage a team to stay focused on one thing long enough to complete a feature? How much can we direct the work when the work is contributed by volunteers?
In order to discuss how to focus work in group volunteer projects, I think it's important to consider how attention functions in the volunteers as individuals.
I originally wanted to do this as a video essay. Partly because of how useful the neurodivergent community on TikTok has been to helping me understand my own patterns of thought and behavior. Mostly because I thought having a face and a voice to go with the message would help reduce misunderstandings and stigma about the topic.
I managed to get about thirty seconds in, using jwz's Cascade of Attention-Deficit Teenagers as a preface:
@keturntok Back when Wikipedia was young and Mythbusters had just aired their pilot, a nightclub owner named Jamie Zawinski described the open source development model as “a cascade of attention-deficit teenagers.”
That was enough to make me realize I'm not nearly as fluent in performance and video production as I am in writing. I want to get this out soon, so we're back to text for now— until I can work out the rest of my TED Talk.
While I empathized with jwz's pain over perennially unaddressed bugs, I was a bit put off by that description. Aside from the flippant use of medical terminology, I knew there were quite a few of us who had been at this for a while now. We weren't teenagers (at least not any longer) and certainly there were many of us who didn't have ADHD, right?
😒
It was about fifteen years later than I got my own diagnosis.
But this isn't a story about diagnosis. I want to share some things I've learned about how executive function works (or doesn't work) in ADHD, and how that shows up in my participation in a project like this.
One of the most useful descriptions I've found is in William Dodson's writing on what he terms the “interest-based nervous system.” We we do things that are
- Interesting. Novelty is a big factor here.
- Challenging. This can also show up as competition.
- Urgent.
Many of us end up leaning a lot on that urgency component to get through life (hello last-minute deadline scramble!), but it also inevitably leads to burnout, so it's not a great thing to use as the foundation of a management system.
The Challenges of Documentation
I writing some documentation recently and noticed it was a little harder for me to engage with than other work I'd been doing recently. It didn't have the same pull as when I'm doing programming.
I was interested in the topic, but I realized that for me, the interest-driven work is mostly the research. Once I understand it, I'm happy to answer questions, but the process of writing up a big document about it doesn't have much interest for me.
I don't mind writing. Sometimes I enjoy it. And I do take satisfaction in job well done when I finish a piece. I think the missing element is challenge. I know the material and I'm confident in my ability to write. It takes me a while to get it right, but there's no suspense about the outcome. The creative tension is too low.
Writing for the benefit of a future audience who may read it someday also has a much less satisfying feedback loop than programming does. I can't just push a button to execute what I've written and see whether it has the effect I wanted it to.
Debugging
Like documentation, troubleshooting and debugging is often neglected in projects like this. But I often find it engrossing and satisfying work!
A bug presents a challenge; a mystery to uncover, a creative exercise to fix. You might call it competitive too: You have to understand something previously overlooked and then make it work better than the previous attempt.
This can break down if I can't set up a good feedback look to investigate the bug. A bug reported by someone else that you can't reproduce on your own can be very frustrating to work on. That's why I place so much importance on having an automated testing framework: I need a way to quickly re-run the scenario to gather more information about it, and confirmation whether my fix works (without breaking anything else).
I suspect another reason I'm comfortable in this role is that I have a lot of experience in the ways software works—and doesn't work—and I have some literacy in many of the layers of abstraction we build our software on.
A bug in a domain that I'm not literate in often feels unapproachable. Like I wouldn't know where to start, I'm not sure what to look for, or whether I'd recognize it when I found it. The creative tension in cases like these is too high; distressing instead of motivating.
Other times I have may some inkling of where to start, but I fear that learning everything else along the way would take me so far off the path of the other work I'd been looking forward to completing.