Catalyst is a company populated by some of the most intelligent people you’re ever likely to meet. Highly complex, brain-stretching problems are what get our developers out of bed in the morning. They’re passionate about what they’re doing and get completely absorbed in their code, and the concepts behind it.
In order to make money from writing clever code though, they need to be able to talk about it. This is the hard part.
To work most effectively, a developer needs to be able to explain their code to their team members, their project manager, and their clients. While a team member is likely to have a high level of familiarity with the systems, processes and language the developer is using, the project manager may have a broader and more general understanding of the work. The client may be a technical expert, or a non-technical decision-maker.
The developer must modify the way they talk about their work, depending on who they’re talking to. This is a skill that takes practice to hone – how do you explain Docker containers to someone who doesn’t know what a server is for?
My job as a communications specialist involves turning this problem on its head – I’m not a developer, but in order to talk reliably and persuasively about what the company does, I need to be able to speak developer.
It’s no good simply expecting the developers to give me the information I need in plain English, with all concepts and jargon neatly translated, all the time – that’s an arrogant expectation for me to have, and a huge ask for the busy devs. Sometimes, they need to talk nerdy to me, and I need to listen.
The thing is, devs need to be able to trust me to speak with authority on their behalf. How can they have confidence in my skills if I wave a hand dismissively at their screen full of code and say, “I don’t care about all that nonsense. Give me the Reader’s Digest version.”
The devs and I need to meet in the middle to communicate effectively. We need to learn one other’s languages in order to do our best work.
Very often in other organisations, this meeting in the middle does not happen. The developers work quietly in a corner of the building, and talk only to each other about what they’re working on.
The higher-ups who control the budgets and make the decisions don’t talk to the developers, so if there’s a problem, the issue may be lost in translation as it moves through the different levels of management. This isn’t great for making solid business decisions.
I encourage both developers and non-technical staff to learn to talk to each other. A little effort from both sides can have huge benefits for everyone, and makes organisations stronger.
Non-technical staff – talk to your developers. Don’t be scared or dismissive – ask them what they’re working on. Ask them about the technologies they’re using to solve problems. You might learn something, and they’ll feel you value the work that they’re doing.
Developers – please be patient with non-technical folk. Go slowly. Ask whether what you’ve said makes sense. Spell out acronyms for them. They find your work fascinating, once they can understand it, and understanding makes it easier for them to support you.
