Working with techies
I’m very pleased to be share another guest post, this time from my friend Ghilaine Chan. Ghilaine is a virtual COO who has spent her career helping technology based companies to be more effective by helping unblock people & processes. In that guise she’s spent a lot of time helping people learn to communicate better with their technology providers, a key problem in the industry. She’s kindly agreed to share some of her wisdom on this topic…
We find it relatively easy to talk to people on a daily basis, but when it comes to getting our message across and asking someone to do, make, or build something we describe, that’s when the fun really starts!
When you have that picture in your head, how do you articulate it to someone so that they have the same image? I think we can agree, it very rarely happens. Lego game anyone? (Someone describes a Lego structure to another in order to build the same structure without seeing it themselves).
Doesn’t it feel like we are all sometimes speaking a different language? I work with many people with different styles in my day and have found that my superpower is being able to translate between varying communication styles to cut through to the important stuff; to get things done.
Perhaps looking at the Lego game again may give some insight. It very much gives clear boundaries, common language and structure that both parties can share and agree on.
And that is where communication needs to start.
You need to define the common language and structure that everyone in the project/team/company can agree upon. Definitions should be clear, simple, agreed and shared.
In my experience working with techies is no different to working with anyone else, you treat others as they wish to be treated.
The “User Manual” approach is a great tool for that (everyone builds a simple guide to how they communicate best, what they value and what frustrates them, it cuts through the presumptions and stereotypes everyone resorts to). You can hear more about it here.
Whilst stereotypes persist for a reason, using them as your guiding light when dealing with people serves no-one.
When articulating what you want, be specific about the outcome you require. Problem solving never happens when someone has a prescriptive list of how things should be done; give them the desired outcome and agree a timeline and things will happen a lot smoother.
When you don’t have deep knowledge of what they are doing, stand back. Be ready to answer the questions or draw diagrams that detail your thoughts. Let them ask the questions that they need answers to, and be ready to have your answers scrutinised and pulled apart at length.
They will question your assumptions and ideas. Not to make you feel bad, but to make sure they have a good understanding of the limitations and boundaries. They will likely come up with things you hadn’t considered - this makes this process both frustrating and wonderful!
Ultimately, you both need to find common ground and not expect things to happen quickly.
Technology is an artform in itself. It may be practiced by people who think logically, but they still need time and space for creativity. Make sure you give it to them, they need that focus time.
Agree a system for updates and discussions. Don’t hassle people randomly when they are building/coding; it can take a lot of time to reconnect with the work and to draw focus back again (studies have shown up to 23 minutes for each distraction).
They need the context of what they are doing. They don’t work in a vacuum and everything is intertwined. When they understand why you are asking for something, they will more fully understand the implications of the decisions that you and they must make. They need to know the why, just like everyone does.
Remember: Treat people as they wish to be treated, ask them what they want or need.
These questions can help you gather the information quickly and ensure you communicate in a way that brings out the best from them:
· How would you prefer me to ask you questions?
· How often can we have a quick chat to keep me updated and in what form?
· What can I do that will piss you off or cause you to be distracted?
· When do you have your focus time/when should I not interrupt you?
· Who else may be supporting/helping you on this project?
· This is how you should contact me to get a quick answer.
· Please tell me as soon as you know if the timelines are going to be missed. Understand that I will follow up if I haven’t heard by the timelines we have agreed.
To give some stereotypes, that may be helpful:
· Often text is a preferred medium for communication (this is why Slack has become so popular with technical teams).
· They may be blunter in their responses than you may be used to
· They need periods of time to get into deep work alone with limited distractions.
· Open plan offices are not conducive to their work, but when are they ever for anyone?
· They prefer a structured approach to an ad-hoc one.
· They need more feedback than “it doesn’t look right”, “it doesn’t work properly”, “I don’t like it”.
I hope you will find this as useful as I have when learning how to communicate with technology people. Please get in touch or leave a comment if you have any questions or anything to add to the conversation!