It's been a while since I've written anything technical (I'm busy writing fiction at the moment), but this post has been brewing for a year, and a meeting today pushed me into wanting to write it up.
I've been diversifying since last I wrote! I've always thought of myself as a 'Jack/Jill of all trades' in software, I'd even like to call myself 'a renaissance man', except I've never been one for pretention.
One of the things I love about where I work, and particularly my current team is that there are always opportunities to 'self outside' of my job title and do something a little differently. This has included working as a scrum master, business analyst, developer, data analyst, it goes on!
An area I really love working in, and this goes back to my love of agile and being a scrum master is facilitation. It's a role I absolutely love, and have really grown into over the years, but it also is one I initially found challenging.
You see, I love contributing ideas and finding direction. That kind of leadership can have it's uses, but it doesn't make for good facilitation, and can (as we'll discuss) have it's limitations.
When my team comes across a problem, it's really easy to look at it, and try and propose a solution. And that's okay sometimes, but with those words I said before, with being a Jack (or Jill) of all trades, you have to remember you're also a master of none.
Generally, when the team comes together, there's a good amount of knowledge in the room. When you can tease that out of them, it makes for better solutions, as well as allowing the whole team to own the solution.
An example might be, we have some problem records in production. How do we fix them?
The shallow solution is just 'patch the data', gather the team together though and you might have one developer come out with 'well, we get this issue every year, it's to do with how one of our legacy parts of the system'.
Now we have two solutions! A quick fix, and a deeper fix. Now we might still go initially with the quick fix, but we can write up, track and look to the future to address the future fix. And that's good!
But how do you get there? I generally find there's a hesitancy for people to speak out. I think a lot of the folks I work with like to internally process things first.
So here's an example of how I handled something in a meeting today, and it's something that happens in most meetings. In this meeting we were looking for a number of initiatives for change (put up on a Trello board), but we needed one to start.
"Okay, we have our epics here, which one should we work on first?"
Silence.
To me, silence is difficult. Yes, with a surname of Talks, and an occasionally loud personality, I have an answer to this. Something I'd like to do.
BUT, I think it will mean more if the team chooses themselves.
So, I play a game of chicken with the silence, holding my nerve.
Internally, I count up slowly. I will give it up to about twenty seconds before I try another tack. I'm aware I'm holding my breath slightly.
Eventually someone breaks the silence with an idea. Once one person has chimed in, another follows.
I keep track of people who've spoken, and try and make some time to ask for thoughts from some of our quieter members to make sure they're included. I've often found some of our quieter team members have as much if not more insight as the other members, and it's always worth inviting them into the conversation (without putting them on the spot too much). Generally this is a low stress question as most people have the get out default answer of 'I agree with what's been said'. But I've often found real diamonds from doing this.
And this, in truth is the biggest tool in my facilitation toolbox, the application of silence through holding my nerve, and accepting some silence in a meeting is no bad thing.
It's something I picked up particularly from some of Gitte Klitgaard;s workshops at ATD. Around 'let other's talk more, talk less yourself'.
Because I expect you'll ask - how do I break the silence when it goes on too long.
- If the question is low stakes, you can put out your own answer. If you have a semi-decent answer, folks will tend to jump on to rubber stamp it. But you're moving the meeting forward.
- If you have the trust of your team, you can provide a really bad, comical answer. This can move things forward, people often find it easier to respond to an idea than come up with something new (this is a technique I similarly use around decision making I should flesh out in the future). But the downside is, if the team doesn't know you well, this can make you seem like you're just dumb.
- Ask someone directly what their thoughts are. This one should be handled with care, as it can make some people feel tense and put on the spot. You need a meeting which feels low stress, with team members you have a rapport with. It's also much easier in a room of people (vs online meeting) as you can pick up from body language clues people in the team who seem to have an idea, but are hesitant. Sometimes just making eye contact can be enough to prompt.
So in honour of the power of silence, here's a Harpo Marx pic...
