When is a joke never funny - when it's running
I caught up with two people last week, on separate things, but they overlapped so nicely, that I thought it would make for a good newsletter.
First person I spoke to was about the dangers of running jokes within teams. The other was to talk about an upcoming event, and how it would be good to ask someone to join us to discuss their role within a team dynamic – loosely titled “Why are you so bloody hard to work with?”
I’ll explain where the overlap sits, but first – here’s a joke to set up the rest of the newsletter.
Q: How many enterprise architects do you need to design a new system or service?
A: One – to make you realise you really needed a technical architect who would play nicely with your development team instead.
So, let’s start with a statement – never foster an environment where you allow a running joke to exist.
It’s as simple as that.
Running jokes are usually born from a degree of frustration or “feedupdedness”. I have been guilty of creating them. Making up imaginary excuses for the tardiness of a team member. Or easing another into a daily stand up with an intro around their inability to recall what they had for breakfast, let alone what they did the day before.
Excuse time: I was less confident in my ability in the role, more needy for the laughs than to actually just get s*** done. I had given up trying to actually get them in on time. I’d tried the usual 1:1 conversations or escalations to team leads, but nothing changed. They turned up late more often than not. We carried on with the running joke no matter what time they turned up.
It was wrong. I should have known that then. There is no excuse.
The running joke was barbed, resentful and the meaning was by no means hidden. Turn up on time, do your work and stop getting me angry every day. How hard can it be?
Which is another reason why you should stop it when you see it play out when teams talk about the roles and people around them. Delivery Managers are self-deprecating. BAs want to take you down rabbit holes. Designers rarely deliver “on time”. Trying to get developers to share information is like getting blood from a stone. Platform Engineers are in a world of their own. Architects ARE. THE. WORST.
Until they are not. Which is usually all of the time.
People always remember the worst of every role through the lens of individuals. If a team had a terrible DM before you, does that mean you will be a bad DM? No, of course not. So why do people all too often allow the generalisation to exist within teams, when talking about other roles?
The criticism of roles is based all too often on what we expect them to do, rather than what they believe they are meant to do.
To see this play out, run a roles and responsibilities session and you will be amazed at the differences between the role holder and other members within the team.
How you run the session, is to get each role holder to write down a series of bullet points around what they believe they do on your project. Then ask them to write another set of bullet points around what they need from the team around them.
Now get the rest of the team to write bullet points on what they think that role does, and a similar list of what they “actually” need from the role. In doing this, you are already assuming there will be differences across each of the lists.
Do it in turn for each role the team has. Talk through the bullet points, come to a common understanding – move forward with the outcomes. Which is why it is good to do it as early as possible (sprint zero, if such a thing exists in your world) to remove any uncertainty.
Remember, keep this a safe space so people can share openly – but in a way that isn’t critical or attacking.
Allowing running jokes to creep in, is often a sign that cracks are starting to appear in the team dynamic and you’re not sure how to stop them forming. Sure, we all need a bit of humour and light relief in work – but not at the expense of others.
The only time this is acceptable is when you are in a Signal group and the person you are making the running joke about is unlikely to read it for another hour or even day later. Even then, you might want to limit how often you do it – in case someone you aren’t… er… subtweeting, subsignalling, substacking… doesn’t know it’s a joke and assumes you’re just a loud mouthed, insensitive delivery manager who is just as bad as every delivery manager they’ve ever worked with. Joke backfired. End of writing purely for one reader.
In summary:
Running jokes are bad and you are bad if you allow them to play out within your team
Not all enterprise architects are bad
/END