How to talk to developers
Boring meetings and balanced conversations 2022-03-15 #product
While developers always risk having too many meetings, they rarely risk having too many conversations (even with each other). Working with programmers goes better when you understand the difference.
Summary
- Developers won’t always show more interest in the details of your work than you do in the details of theirs.
- Developers don’t do their work in meetings.
- Developers master asynchronous communication to protect time for focused work.
- Engage developers in mutually-important conversations.
People and their interests
Non-programmers risk misinterpreting developers’ meeting avoidance as unwillingness to talk to people. Developers love talking to people, but not about every topic, and not in every venue or group of people. Alistair Cockburn explores this in his 2001 book, Agile Software Development:
Programmers are typically stereotyped as non-communicative individuals who like to sit in darkened rooms alone with their computer screens. It is not a true stereotype, though. Programmers just like to communicate about things they like to communicate about.
Commercial software product development probably requires developers to spend as much time talking to each other as they do coding. They mostly talk about coding, though, which you should bear in mind the next time you ask a developer to jump on a call about your non-coding problem.
Talking to developers doesn’t have to mean talking about code, though. Software development includes many coding-adjacent topics like user-interface, process and data-model design, not to mention software development methodology and organisation design. As a product manager, I don’t particularly want to talk about code itself, but there are plenty of interesting software design topics that only come up during coding.
Meeting-avoidance
Developers don’t avoid people so much as they avoid bad meetings. Developers don’t hate all meetings; they hate:
- unnecessary meetings that ‘could have been an email’
- meetings with no explicit purpose
- meetings whose actual purpose involves power games
- meetings that reduce their productivity, for which their manager penalises them
- meetings that are all of the above, especially.
Getting developers talking during meetings requires the good meeting practices that all meetings deserve, as well as the psychological safety to participate. When a developer (or anyone else) attends a meeting without speaking once, blame the meeting, not the developer. If you fail to fix bad meetings, developers will reward you with progressively more passive-aggressive meeting avoidance and lack of participation.
Where the work happens
People in management roles do a lot of their collaborative work during meetings. Product management’s information sharing and alignment happens primarily directly between people, and doesn’t all get written down. A product manager may have achieved a desirable result when everyone understands and agrees.
Meanwhile, developers don’t generally get rewarded for results other than working software. Meetings contribute indirectly, at best, not least because non-coders tend to frown upon coding during meetings. Meanwhile, developer collaboration features more asynchronous message-based interaction, which doesn’t look like a meeting. Team programming doesn’t look much like a meeting either.
The conversation challenge
In the end, figuring out how to talk to developers means finding common ground and shared interests, and joining conversations about them. And if you think that software developers need the ability to talk about the business, consider instead whether business people should spend more effort on their own ability to talk about software development.
