How do you work with non-engineers?
I was asked this yesterday, and I was rather pleased with my answer, so I’m reproducing it here.
It starts by respecting non-engineers as equals. Some software engineers have a superiority complex and treat everyone else like dunderheads, which is a terrible foundation for a working relationship. Respect the competency and expertise of your peers, including those who work in a different field.
I dislike the term “non-technical” when it’s used as synonymous with “doesn’t write code” or something similar. People can be technical – that is to say, skilled – in disciplines which have nothing to do with software. Calling somebody “non-technical” is a subtle way to belittle them.
Then talk to people in their own terms. Don’t try to overwhelm them with engineering jargon or unnecessary detail. When you need to explain something, describe what they need to know to do their job, and in a way they’ll understand.
For example, when I’m describing Amazon S3, I might call it a “distributed cloud object store” when chatting with another engineer, but a “place to put files” when talking to a librarian. The second explanation is accurate and makes sense, but it doesn’t explain more than they need.
(This doesn’t mean dumbing a topic down down, or offering a patronising explanation. Remember: respect their competence and expertise. They’re not unintelligent, they just care about a different level of detail to engineers.)
Finally, I try to relate technical topics back to problems they care about. What’s the business goal they’re trying to achieve? How does technology help to drive that forward? Those goals are what they actually care about; they’re what should be driving our work.
Wellcome is a museum and library, not a software factory. Technology should be led by the organisation’s needs, not the other way round.