On Monday and Tuesday this week I’m attending DevSecCon in Boston – a city which is much more pleasant when it’s not raining or snowing, which it often seems to be doing while I’m here. There are a bunch of interesting talks[1] and workshops, and I was asked, at the last minute, to facilitate an “Open Space Discussion” at the end of the first day (as two people hadn’t arrived as expected). Facilitating discussions is about not talking all the time, but encouraging other people to talk[2]: my approach to this is to tell a story, and then encourage them to share stories.
People enjoy listening to stories, and people enjoy telling stories, and there is a type of story that is particularly useful and important in the world of work: “war-stories”. Within the IT industry, at least, this refers to stories about experiences – usually bad experiences – from our day-to-day working lives. They are often used to illustrate a point or lend experiential weight to an opinion being put forward. But they are also great learning experiences.
What I learned yesterday – or re-learned – is the immense value of conversation with our peers in a neutral setting, with no formal bounds or difference in “rank”. We had at least one participant who was only two years out of college, participants with 25-30 years of experience, a CISO of a major healthcare provider, a CEO, DevOps engineers, customer-facing people, security people, non-security people, people with Humanities[4] degrees, people with Computer Science degrees. We were about twelve people, and everybody contributed, to greater or lesser degrees. I hope that we managed to maintain a conversation where age and numbers of years in the industry were unimportant, but the experiences shared were.
And I learned about other people’s opinions, their viewpoints, their experiences, their tips for what works – and doesn’t work – and made, I hope, some new friends. Certainly some new peers. What we talked about isn’t vitally important to this article[5]: the important thing was the conversation, and the stories they told that brought their shared wisdom to the table. I felt, by the end of the session, that we had added something to the commonwealth of knowledge within the industry
I was looking for a way to close the session as we were moving to the end, and hit upon something which seemed to work: I encouraged everybody to spend 30 seconds or so to tell the group about an incident in their career that they are proud of. We got some great stories, and not only did we learn from them, but I think it’s really important that we get the chance to express our pride in the things that we’ve done. We rarely get the chance to boast, or to let people outside our general circle know why we think we should be valued. There’s nothing wrong with being proud of the things we’ve done, but we’re often – usually – discouraged from doing so. It was great to have people share their various experiences of personal expertise, and to think about how they would use them to further their career. I didn’t force everybody to speak – and was thanked by one of the silent participants later – and it’s important to realise that not everybody will be happy doing so. But I think that the rapport that we’d built as a group meant that more people were happy to contribute something than would have considered it at the beginning of the session. I left with a respect for all of the participants, and a realisation of the importance of shared experience.
1 – I gave a talk based on my blog article Why I love technical debt. I found it interesting…
2 – based on this definition, it may surprise regular readers – and people who know me IRL[3] – that I’d even consider participating, let alone facilitating.
3 – does anybody use this term anymore?
4 – Liberal Arts/Social Sciences.
5 – but included:
- the impact of different open source licences
- how legal teams engage with open source questions
- how to encourage more conversation between technical and legal folks
- the importance of systems engineering
- how to talk to customers and vendors
- how to build teams through social participation[6]
- the NIST 800 series and other models to consider security
- risk: how to talk about it, measure it, discuss it with other functions within the organisation.
6 – the word “beer” came up. From somebody else, on this occasion.
Alice, Eve and Bob - a security blog 