Of all the skills I’ve learned so-far during my almost 20 years as a software engineer, perhaps the most valuable isn’t even a technical skill: Namely, how to get the most out of difficult conversations and meetings.
Some conversations are difficult because the technical content is deep, or tough, or unclear, or each person involved has a different level of understanding of the content. Others are hard because at least one ego is present and is intent on taking the conversation in a particular direction. Some conversations involve warring parties, people who have “always” disagreed, or teams with seemingly different remits.
None of these conversations go well if the individuals involved tackle them as individuals. Someone (preferably at least one person) needs to lead the conversation from the viewpoint of the whole group, to orchestrate the best outcome, to see things from both sides, to question, to summarise and to put their own viewpoints alongside those of the others rather than ahead of them, no-matter what affiliations they may have. Ideally, everyone in the group would do this, removing the need for someone to “chair” the meeting, which I think usually disempowers other people present.
To this day, I’m still amazed by how few people in the working world, engineers and non-engineers alike, learned these skills. Meetings and conversations cry out for them, but perhaps only once you’ve seen how well those conversations can go with a few small changes.
This week, I was in a meeting with 8 highly-intelligent engineers. None of them brought prior resentment or disagreements to the meeting, and the aim of the meeting was to decide on an approach to a certain software-related activity. But, each spoke primarily from their own viewpoint and seemed collectively confused about why the meeting was in chaos. In software engineering terms, each seemed to prefer a depth-first approach to the conversation, choosing to disappear down a rabbit warren into details that they felt familiar with, but which were possibly irrelevant, or out-of-context, or not-yet-introduced to the others present. Months of prior inaction brought a slight sense of powerlessness to the meeting, and the historic context was painted negatively, risking a sense that making changes in future was futile. The reality was that these 8 engineers had a blank canvas, total freedom and could choose whatever approach suited the group as a whole… a far more positive reality than the atmosphere in the meeting suggested.
I can’t sit through such meetings without trying (even when it’s inappropriate) to lead them now, or at least to throw in suggestions for how the meeting might flow better. Sometimes this involves asking someone to back up and start describing a topic from a different viewpoint; usually with a wider context, with more background, or postponing discussion of details until later. Other times, people need to be asked to put aside the assumption that prior differences between teams can’t be tackled because, if you go on that assumption, there really is no point in having the meeting and we should all just give up and go home 😉 People often feel powerless and they sometimes need reminding that then can ask for what they need, rather than remaining silent and assuming they won’t get it. They need reminding that they can change things, but they need to choose to.
All of the above suggestions, if dropped subtly into such meetings by someone, can change the dynamic significantly. People start to think about what they’re saying and try to describe topics in a way that others will more readily understand, using common language or explaining terms. They start to search for common ground. They start to see that long-standing situations can be changed if they entertain that possibility. The meeting starts to have a purpose, and therefore an outcome.
Of all the skills I’ve learned so-far as a software engineer, this non-technical one is perhaps the most valuable, and the most applicable to other contexts.