Team

I’ve written quite a lot over the last few weeks about Safety in team discussions. What I haven’t really discussed is how to detect when the safety is starting to fail. Imagine you’re in a conversation with someone, at work or at home and they’re starting to feel unsafe. We know that this means they will stop sharing and will result is poorer group decisions. But how do we know if someone is feeling like that and what can we do to prevent it?

If you haven’t read it already I strongly recommend picking up a copy of the book Crucial Conversations. In it, the authors discuss that people generally go one of two ways when they’re feeling unsafe. They either go to silence or violence.

When someone goes silent they often stop talking or become very monosyllabic in their responses. Perhaps they want to shut down the conversation or move onto another, safer topic or maybe they’re only sharing certain parts of the story – the parts which support their argument rather than discussing the potential problems with it. However silence manifests it’s usually because the person doesn’t feel comfortable with the topic and wants to move on or gloss over the real issue.

black and white black and white depressed depression

Photo by Kat Jayne on Pexels.com

Other people tend to go to violence. I’m not talking about physical violence (at least I hope we’re not making people so unsafe they have to lash out). I’m talking about attacking an idea or, even worse, a person. Comments like “that’s the stupidest thing I’ve ever heard” or “only a moron would say that” are attacks. People raise their voices and try to dominate the conversation through shear volume rather than calmly discussing the topic with someone else.

man couple people woman — Photo by Gratisography on Pexels.com

It’s important to realise that both of these are natural reactions when someone feels insecure discussing something. It may be that you’ve said something which has upset them, or it may be that they’re worried about the whole topic of conversation.

In the example I gave a few weeks ago the developer had an idea which he refused to share with the group because he didn’t think the team would listen to his opinion. However, he could equally have turned to violence and tried to force his point on the group by making them feel unsafe challenging him. Both of these are defense mechanisms. It’s our role as colleagues, as human beings, to look for signs that someone is starting to feel unsafe in a conversation and to look for ways to reassure them so we can resume constructive dialogue.

Collaboration is hard, if we really want the best decisions then we need to hear all viewpoints and listen to everyone’s experience. We can’t do that if we bulldoze our view too firmly. The next time you’re passionate about an idea take a look around you and see how others are reacting to you… are they going to silence or violence? We cannot change other people’s behaviour but if we try and support other people’s confidence then we’re likely to get ideas and suggestions presented which we’d never have considered ourselves – after all, isn’t that the point of a team?

Annual reviews are often one of those things we do as a box ticking excercise. It’s dull, time consuming and there are often more interesting geeky projects you’d rather be working on.

Words like SMART buzz around our brains for a few weeks and then are promptly forgotten (much like the goals) until the same time the following year when each goal is ticket off as “Done” or “No Longer Relevant”.

Surely there’s a better way?

Let’s look at what SMART stands for…

Specific
Measurable
Attainable
Relevant
Time Constrained

Your business may have different words but the jist is the same.

I want you to think about these words differently. Instead of writing goals for someone to achieve I want to think about User Stories. It’s reasonable to demand that any PO writing new features for the backlog should create them so they are Specific, have good Acceptance Criteria, be feasible to implement, be a valuable addition to the software, and should fit into a single Sprint.

In other words SMART is just another way of setting detailed and unambiguous instructions!

So now we know that SMART is simply a way of writing clearly let’s look at what goals you should set.

What do you expect your Team Member to be doing for the upcoming year?

This may sound like an obvious question but in my opinion annual goals shouldn’t all be about Continuous Personal Development or an arbitrary “I’d like to lean that” because these are the first things which will be abandoned when you have a tough day. Instead look at what your department goals are and propagate these through to your team.

If you have a major release coming up then set that as one of the goals. If you need to analyse system performance or memory usage then write it down. What you will find is instead of irrelevant targets which will be abandoned in favour of more pressing work your team will suddenly become accountable for getting the releases out to customers. Not only that, but they will see that their day to day tasks are being used to measure performance instead of the “Nice to Haves” which were abandoned as soon as the year hit a rough patch.

You will quickly find that most developers will much rather have a goal of “Create Offline Sync Mechanism as specified in Feature 123 before the end of January” than something vague like “Improve the Support mechanism”. For one thing there’s a lost less ambiguity as to whether it’s actually been achieved! Remember, less ambiguity means fewer awkward conversations when you come to assess goals, that has to be a good thing!

In conclusion, setting clear (or SMART) goals for your team which actually reflect the work they’re going to be doing day to day is a great way of getting investment in your department’s objectives and helping making those annual review forms much more relevant. Learning goals are good, but they shouldn’t be the core of a Team Member’s assessment.

Tag: Team

Just How Safe Do You Feel?

Setting SMART Goals for your Team