Engineering teams are like ADHD brains

Exploring parallels between managing a software engineering team and managing an ADHD brain

For, ahem, personal reasons, I’ve been researching ADHD recently, looking at the common symptoms and behaviours, and how to manage them. It was while looking at “managing ADHD” stuff in particular that I was suddenly struck by the similarity of many of the things I used to do when managing engineering teams. I was struck by the parallels between ADHD brains and engineering teams, how they operate and the things we do to try and manage them to be more effective and efficient.

This article explores those similarities as an exercise in looking at things differently, to perhaps help us understand both ADHD and tech teams a little better.

It goes without saying that I’m not a doctor, psychologist, or neuroscientist. And of course, all teams are different, and everybody with ADHD experiences it differently. This is an article of curiosity, not a manifesto or declaration of a new truth.

Enough caveats? Okay, let’s move on.

Demystifying ADHD assumptions

A quick bit on ADHD to give the rest of the article some context, as ADHD is widely misunderstood. It’s often thought of purely in terms of the disruptive kid in school, who can’t sit still and doesn’t pay attention or do what they’re told. But it’s somewhat more nuanced and varied than that. There are distinct subtypes and degrees of severity.

The name itself doesn’t exactly help with this common impression: Attention Deficit Hyperactivity Disorder.

Nice.

It’s not just hyperactivity

Amazingly, physical hyperactivity isn't a symptom for everybody with ADHD. Yet because it’s in the name it’s understandable that we believe otherwise. According to NICE (National Institute for Health and Care Excellence), the inattentive subtype accounts for 20% to 30% of cases [source]. There’s a pretty good case to be made that this number is higher in reality, as these cases are less likely to be diagnosed as they have fewer outward symptoms.

“Attention deficit” is misleading

“Attention deficit” labels the external experience - it’s what other people see. The internal experience is different, I’ve heard it described as having too much attention. Paying attention to many things at the same time. Naturally, to the teacher, parent, partner, or manager this displays as a lack of focus on them.

A common trait which serves as a flip-side to this is hyperfocus. This is the ability to shut off everything else and get into the ultimate flow state on a single thing. Sounds great. The catch being that getting into this state is hard to predict, engineer, or direct.

So perhaps it’s helpful if we think of it less in terms of “attention deficit” and more in terms of focus management.

There is so much more

There is a lot of research going on to explore ADHD, and so our understanding grows and shifts with the release of new studies.  The last few paragraphs are not all-encompassing by any means, they are merely intended to point out a couple of the more commonly held misconceptions.

And so, onto the parallels between ADHD brains and software engineering teams.

Parallels of ADHD brains and engineering teams

These are some of the parallels and similarities that I’ve noticed from my research and my experience managing engineering teams.

High context and cognitive load

ADHD brains and software engineering teams both maintain more context and a higher baseline of cognitive load than average.

Software engineering is hard, it is constant problem-solving. With each problem being part of a larger problem containing multiple considerations from customer needs, to reliability, to scalability, to practicality. Not to mention the complexity of the average tech stack these days. There are many things that these teams have to pay simultaneous attention to.

And this is where the parallel to the ADHD brain comes in: ADHD brains also pay simultaneous attention to many things. Absorbing all of this information carries a high cognitive load, but it can build deeper understanding and context.

Software engineering is hard. It’s little wonder that there are more tools, frameworks, and processes out there for managing tech teams than any other type of team. But well managed, these teams can regularly produce brilliant work.

And the same is true for ADHD brains.

Interruptions and distractions

Okay, so how many notifications interrupt you on a daily basis? ADHD brains are wired to be highly distractable, and surprisingly so are many engineering teams. Two of the biggest culprits are email and Slack.

Both are invaluable tools for running a business and running a tech team, but left unmanaged you quickly drown in the noise. It’s great that so many things integrate into Slack. Git commits, PRs, code review requests, build status, and service interruption alerts … they all live alongside your DMs, team channels, project channels, meme channels, org broadcast channels and more.

(I freely admit that I’m still slightly triggered by the default Slack notification sound!)

Extremely useful for work, but if you want to get work done you have to spend time and energy working out how to manage those potential interruptions and distractions, whilst allowing the important ones through.

And so it is with the ADHD brain. Left unmanaged it is subject to overwhelm by interruption.

Focus

Engineering teams tend to be among the first and most vocal advocates for “meeting-free mornings” because they value so highly the time to focus. It’s not just at the team level that software engineering is “high context and high cognitive load”, it’s at the individual level too. It requires focus. And with all of the interruptions and distractions around, we need to actively and explicitly encourage the conditions for focus and flow states.

This relates to what we were talking about earlier, with the ADHD trait of hyperfocus. The challenge of course is that it’s not just a switch you can flick on.

I remember working very hard to try to reduce the number of interruptions that came into my team. I’ve given talks to entire departments and regions on the impact of interruptions and how a “quick question” has an unfathomably high impact on flow and productivity.

So the question here is, what can you do to improve the probability of more flow states by enabling the conditions for focus?

Shiny-object syndrome

ADHD brains tend to be fired up by new ideas and experiences, unlocking new possibilities. Most engineers I know - not all, but most - love new technologies. There’s a love of learning and trying new things. And perhaps - with a bit of cynicism - there’s also a degree of resumé-driven development at play.

But in our hearts, we all know that new technology is not necessarily the best choice. There’s a lot to be said for maintaining a consistent tech stack and thoughtfully adding to it or adjusting it over time.

The challenge - for teams and ADHD brains - is in that discernment. You need to feed the need for indulging in shiny-object syndrome whilst not over-investing or going completely down the rabbit hole for absolutely everything.

Prioritising tasks

A lesser-known symptom of ADHD is the inability to prioritise tasks, especially tasks that don’t have a logical order. In the ADHD brain, they all have an equal priority, which is why the visible impact of this is so many things started and not finished. It’s common for a  person with ADHD to seem to have a lot of plates spinning all of the time. And this is because they just don’t have an in-built prioritisation system. To prioritise takes real conscious time and effort.

“That’s ridiculous!” I hear you cry, “Surely this doesn’t apply to tech teams?”

This is where we have backlogs, sprint planning, and entire - very regular - meetings to decide what will be worked on at any given time. Leave it to chance and everyone will see different priorities and start working on different things, leading to a chaotic mess of unproductive activity. Which none of us have ever seen, right? Right?

Add to this conflicting priorities from different stakeholders - and sometimes, just for fun, the same stakeholder - and you’ve got a real challenge on your hands. If you’ve ever asked “what’s the number one top priority?” and you’ve been presented with a list of five “number one” top priorities you get the picture.

That takes some active management.

Breaking down tasks

A common struggle for those with ADHD is getting started on large, complex tasks. Even if it’s well within their capability, the enormity of everything that needs to be done is overwhelming. Much like the challenges with prioritisation, it feels impossible to know where to start. Of course, the ADHD brain is very good at finding other things to do instead. This is likely interpreted by others as procrastination, causing delays, and not focusing on the “right” thing.

The way to manage this, of course, is to break down the overwhelming task into smaller, more approachable tasks and prioritise these smaller chunks.

You can probably see where I’m going with this in relation to managing engineering teams. So much of the entire process of being effective and efficient is based around this very issue: breaking down big insurmountable tasks into smaller manageable tasks to generate a sense of momentum.

A Jira ticket called “Build real-time API” is not going to cut it. And we all know that. (Right? Yes? Good. I believe you). We all have ways of breaking it down into manageable activities and organising them in such a way that the team can get started with minimal fuss and deliver the solution.

I will tell you that I have had to coach many a junior engineer in not jumping straight into the code. Break down what you’re going to do, plan it out, thank me later.

On the whole, as an industry, we are used to putting in that effort upfront. It’s just a part of managing the work and managing the team. But for ADHD folk who benefit from this approach in multiple scenarios in life, it is less of a common habit, possibly because it’s not widely modelled around us.

Managing time and timeliness

Many ADHD brains experience something called time-blindness. It can manifest in different ways, a couple of common ones are losing track of time and underestimating how long something is going to take.

I do not know a single engineer who consistently over-estimates! But we have found ways to manage this in teams, through a combination of training, measuring, and reflecting.

It’s a conscious activity when running a good software team, just as it needs to be a conscious activity for an ADHD brain.

ADHD brains are also often somewhat deadline-oriented, it seems to help with both the prioritisation and the focus issues we’ve discussed above. Without deadlines, things are likely to get done in either a logical process order or based on whatever seems most interesting. And they will take longer than anticipated.

And again, we’ve seen a parallel in running software teams. It’s just the solution to manage it is so common now that it might not be entirely obvious unless you’re old like me! Think waterfall vs Agile. We’ve gone from having one big deadline months or years away, to creating smaller deadlines every two weeks.

Conclusion

Here ends my little exploration of the similarities between managing ADHD brains and managing software engineering teams.

ADHD brains take more active management than other types of brain. Software engineering teams take more active management than other types of team. Unmanaged, the results are mixed and unpredictable. Well managed, the results can be spectacular. Neither is easy, either is worthwhile.

So, what do you think? Is this an interesting lens? Do you see the parallels and connections that I see?

---

---