Communication Strategies for Supporting  the Neurodiverse Builders on Your Team

Expectations for success should be over-communicated. And expectations-based comms should always be open, two-way conversations between builders and managers. 

A key part of the role of a product or project manager is to clarify expectations for success, e.g.  when and what’s required on a task or feature. Especially with ND devs, it helps to communicate these expectations (think: requirements) in multiple modes, and follow up with questions and a conversation. 

If a PM uses communication as a one-way street to tell a developer how to write code, or over-prescribes a solution, it can rankle developers who enjoy the process of problem-solving. The key here is to frame expectations for success as a dialogue, allowing everyone to voice their opinions. This includes a conversation about how much an individual developer may need or want a PM’s guidance on *how* to code. 

Read code reviews - in detail - in order to understand what kind of feedback your devs are getting. 

A particularly nitpicky code reviewer can distract a developer (especially a ND one) with “nice to have” feedback that sends them down a rabbit hole. They may chase down a solution while you're desperate for the core feature to launch with or without that particular detail. If you see non-essential feedback slowing down velocity, talk to your dev (and the reviewer) about how this feedback can be pushed to later releases or up-leveled for PM feedback on priority. 

Depending on your delivery, this could be perceived as micro-management. A developer may also take this as you saying they don’t know what’s important to work on. Make it clear that your job is to help prioritize and translate requirements with respect to timelines so that velocity can stay high. 

Establish swimlanes, or areas of ownership in a project, within a feature, within an epic (set of tasks), etc. 

Be sure to re-clarify the ownership areas as the work changes and task owners shift.

Clarifying ownership areas on complex projects and features can help ND devs understand where there's freedom of decision, and where it's a collaboration. Calling out specific areas where collaboration will be expected can help them avoid guessing at when to bring in others. 

As work evolves, ownership areas can get blurry and technical areas can overlap. Swimlanes, if they’re not consistently updated, can add more confusion and lead to work falling through the cracks.

Swimlanes can feel too restrictive for a broad research effort, and may make it more complicated to get the work done. Again, if you try swimlanes, work WITH your team to see if it sounds helpful. 

If and when a developer doesn’t finish a task on your expected timeline, have a conversation about WHY they didn’t. Don’t make assumptions. 

Frequently for ND all developers, things take longer than they expect. If they’re willing to talk to you about why that’s happening, they may also be open to discussing together how to change their other priorities or talk to another PM that’s been bugging them about something else. 

If you attack someone for failing to deliver on time, this will only cause harm in the relationship and won’t improve velocity on the team. It could put a developer on the defensive or bring up rejection sensitivity if you probe into their process critically.

Be careful with when and in what context (i.e. public or private) you approach individuals to dig into the quality and timeliness of their work product.