Difference between pages "ClsXlca2015 burnout" and "ClsXlca2015 recognition"

From LCA2016 Delegate wiki
(Difference between pages)
Jump to: navigation, search
(Resources)
 
 
Line 1: Line 1:
Notes from the Burnout discussion at #clsXlca
+
Notes from clsXlca 2015 Recognition discussion
  
Summary:
+
Recognition
  
We focused on burnout, warning signs of, manifestations of, strategies for avoiding,
+
What do we mean by "Recognition"?
  
We did not end up covering:
+
How would you like to be recognised?
retention, recruitment, succession planning, sustainable pipelines and handovers, creating engagement. having a separate life outside of foss.
+
  
We did end up covering health and wellbeing, with an emphasis on mental health.
+
Recognise contributions to a greater effort.
  
Burnout, retention, recruitments
+
What does it look like?
health and well being - body health, mental health, community health. separate life.
+
  
succession planning / sustainable piplelines and handovers.
+
(Individual Experiences)
 +
** Verbal
 +
** Specific, timely and explicit
 +
** Linked to org/communities goals
  
In terms of responses to burnout and stress, they seemed to fall between two categories
+
From whom?
1) withdrawing, either from the particular project causing harm or from everything in general
+
** Leaders giving thanks has certain gravitas
2) working harder, either on the particular project causing harm, or procrastinating on other important, but less urgent tasks.
+
** Peers giving thanks means something different
 +
** 'Members' giving thanks to 'Leaders' for doing leadership things is rare and just as highly valued.
  
Common themes in the strategies involved
+
Some people prefer their recognition to be private. Some prefer it to be public.
* solitude
+
* exercise
+
* nature
+
  
mental health - invited mental health professionals to speak
+
1:1 directed thanks is powerful; in person is often preferred within our discussion group; email, replies to public postings on mailing-lists/forums are all nice too.
  
is it helpful? definitely fosters openness. bof for mental health.
+
How do we foster a culture of recognition?
  
Induction information - where to get help, external resources like lifeline.
+
Acknowledging code contributions and seeing them being used. Having patches merged in by that person who the community knows only merges the very best patches is a form of recognition, but it's not an accessible form to newbies who don't have that map yet.
  
Professional sessions with shrinks at conferences. Difficult to give feedback, getting metrics.
+
Other people engaging with your code, either by linking to it, building on top of it, or extending it are forms of passive recognition that you're building something useful.
  
Professional consqeuences for being open about mental health issues. There is a fear of being too open for fear of impact on professional/monetary goals. Can be the cofnerence organisers job to normalise the use of mental health services.
+
When a peer comes to you and says "that's a beautiful piece of work" (verbal, face-to-face worked. email didn't work for this person).
  
Using different words to lessen the stigma - brain mechanic.
+
Recognising consistently good work is equally important as recognising someone raising their work to that level.  
  
Like any disease, early intervention is key.
+
One piece of recognition is a project leader tweeting that someone made a strong contribution to a release and that was excellent.  
  
 +
If the recognition is written down it allows the recognised contributor to return to it at times when they are feeling like an imposter and get a boost.
  
Responsibility of the organiser community  to be proactive vs reactive.
+
Sometimes when you're the public face of a team or group, you will get the recognition for the work they do and you want to pass that on but don't know how.
  
Burnout.
+
One person liked it privately, really specific and didn't tend to return to the recognition.
  
How to avoid burnout? volunteer management. Big bad flag is delegatign to folk who are overcommitting.`           
+
Some times gifts work, not starbucks gift cards, but cultural artifacts (things that relate to the mascot), techie gifts and whiskey are all examples of gifts that work. Some people give team based swag (tshirts) which provides identity and recognition.
  
Volunteering Australia is a resource for planning.
+
Relating it to personal or organisational roles makes it more powerful.
  
A lot of basic business management, clearly layed out contracts.
+
One way we recognise someone is by introducing them to other people and saying "This is $foo, they fixed that awful bug we had sitting in the tracker for weeks and they're awesome."
  
Causes? Boom bust cycle as a regular way of being organised.
+
We recogonise people by attending their talks at cons and paying attention.
  
Lack of supportive environment. having a feelign of needing to be a perfectionist, havnig to do *everything* to be perfect.
+
Some times recognition comes in the form of grant money for an org's goals or funding a specific development effort.
  
In a committee, 20% doing all the work, 80% riding on coattails. Normalised burnout, small number of people expected to burn out.
+
If you don't know how to recognise someone's work you can ask them what recognition they want. You may have to manage an unrealistic or impractical request/expectation here. [ASCII DRAGONS? ;)]
  
Over working in our worklives, too many hours at work.
+
When you do your release blog/notes/files include everyone who contributed to the community in the thanks.
  
LA specific, not resetting of expections of conference from year to year.
+
Code is tracked by SCMs. Translations are sometimes tracked by specific translation tools, sometimes by SCMs. Art assets in SCMs. Other contributions to the community tended to be tracked in peoples heads or in email archives (having project-by-project email aliases is useful here). There may or may not be a good technical solution to tracking these.
  
What is burnout?
+
There are tools for tracking and reporting on metrics on who's replying to emails, irc requests and forums (http://bitergia.com/).
  
Burnout is knowing how to do a thing, but not getting the mental energy to begin. Project/field specific complete lack of motivation to do a particular task.
+
Some of the tools we use to track attribution don't work right for all use cases (author, reviewer/comitter, QA).  
  
Warning signs, manifestations. - constantly feel like you're getting nothing done, regardless of work. Self care routine goes away, project become all consuming. Weight gain, loss.  
+
Metrics can't trump culture. There was talk about how gamifingy sometimes works but sometimes causes more problems. Fostering a 'culture of recognition'.
  
Pulling back from everything.
+
Discuss the ways in which you do your recognition.
  
Getting colds and flus.
+
Sometimes recognition is tied to the release cycle, some times it's periodic.  
  
Specifically wants to quit particular project.
+
Recognition can lead to a feeling of belonging which can lead to engagement.
  
Get neurotic about perfomance and work harder.
+
When people submit pull requests a bot replies on github with a 'we'll get back to you within X amount of time'. It was suggested that people who contribute to maintaining that SLA could be thanked.
  
Participate less socially, withdrawal.
+
Examples:
  
Filled with crushing despair, (different despair to depression)
+
An org bought a bunch of postcards and at the end of a con told their attendees to write thankyous to people who couldn't be at the con and the org then posted them out.
  
General anxiety, must work harder, be better. Feeling of imposter syndrome.
+
One team member bought a bunch of hats which their projects mascot wears and sent them out to the core dev team.
  
Dwelling on thoughts of failure. Anxiety spikes. Withdrawing.
+
We give commit access as recognition of work and sometimes maintainership as recognition of awesome.
  
Being angry at everything, things that used to bring you joy.
+
Release notes, Authors files, commit logs.
  
Withdrawing socially, email isn't always the best communication techniques.
+
Merging code is recognition of the contribution.
  
Resentful of people asking you to do things.
+
In Openstack, regular code contributors get ATC status which gives them voting rights on tech ballots for a year (there are other ways to get ATC status too).
  
Sleep withdrawal, alcohol. Unable to clear the mind.
+
Some websites put badges next to the user profile or the user name when they post.
 
+
Overcommit to displacement activities. Procstibaking.
+
 
+
Two basic strategies, half completely avoid, half work even harder. Some do both, super procastination.
+
 
+
Strategies to avoid:
+
 
+
Getting back to nature, camping. being away from mobile phone coverage
+
and internet.
+
 
+
Travel to a different environment. Doign a reduced pomodoro thing to start one thing. Spoons analagy, quantifies how much energy you have. "But you don't look sick" blog.
+
 
+
Clearing head of tasks. Writing those thoughts down.
+
 
+
Going for a bike ride.
+
 
+
Talk with family and friends, rant at them. Embrace the actual value of relaxing and not doing anything, it can be recharging.
+
 
+
Giving team members a break, communicate that everyone needs time occasionally. Giving yourself breaks on the weekend.
+
 
+
Changing life styles. Relearning happiness, try something that used to make you happy, it might make you happy again.
+
 
+
Motorcycling. Solitude. Things that involve nature, wind. Thinking about real things rather than man made things.
+
 
+
Once a week have a massage. Blocking off the weekend for myself. Sleeping in, relaxing. Shopping, surrounded by people but dealing with them in solitude.
+
 
+
Mandatory hour of reading everyday. Mandatory dinner with partner.
+
 
+
Leave the mobile phone at home, go out and disconnect. Being aware of how many spoons you have, and working within that.
+
 
+
Do something orthoginal, completely different to bloody computer problems.
+
 
+
Encourage others to tell you that you've got the signs of stress.
+
 
+
Playing the piano.
+
 
+
Getting random thoughts onto paper in an organised way, things look much easier to deal with in that state. putting small things onto todo list, being able to strike small, simple things.
+
 
+
Learning to quit things when there's too much.
+
 
+
Changing contexts.
+
 
+
Letting the others in your group know that you need some time off.
+
 
+
Micro strategies - helping other people with burnout/stress.
+
 
+
Plan non refundable weeks away on holiday, force yourself to take a break.
+
 
+
One strategy to get support from the community so we don't burn out.
+
 
+
Have a buddy who knows your weeknesses, call in with them keep organisied. Pair organising.
+
 
+
Standing down from lots of little tasks to give msyelf time. Saying no.
+
 
+
Being public about personal issues, being transparent about trigger points.
+
 
+
Letting go of the expection that you'll fix everything.
+
 
+
Not having complete ownership of a task, being able to hand off to someone else.
+
 
+
Letting something be done to a C grade, not an A grade.
+
 
+
Succession planning, doing it, either formally or informally.
+
 
+
Let others know when stuff is getting tight, so the group can fix it.
+
 
+
Say NO a lot. Being public about where you're at, others in your group will notice and help.
+
 
+
Build a group around you that you trust, that you can call on immediately.
+
 
+
Know your scope, know what you're promised to do, know what you're capable of doing, saying no if a new tasks falls outside that.
+
 
+
Have a plan B for stuff. Tell close friends your warning signs.
+
 
+
communicating clearly and on time. Being clear to team members that no is a perfectly reasonable resposne sometimes.
+
 
+
Know your limits, delegate when required.
+
 
+
We've noticed that we all have these great techni8ques of escaping stress and burnout, but we perhaps don't deploy them regularly enough to avoid burnout in the first place.
+
 
+
Work heroism can be echoed in project heroism.
+
 
+
Per conference - Chillout room. quiet room, bean bags, videos of kittens..
+
 
+
Realising that a lot of people having issues like social anxieties that may not be obvious.
+
 
+
Attendees:
+
Daniel Spector
+
 
+
 
+
== Burnout ==
+
 
+
What is it?
+
 
+
== Discussion ==
+
 
+
 
+
== Actions ==
+
 
+
 
+
 
+
== Resources ==
+
 
+
* http://burnout.io/
+
  
 +
"Shout Out Wall" (post it notes on a wall at cons to give thanks).
  
 
[[category: CLSXLCA]]
 
[[category: CLSXLCA]]

Latest revision as of 18:43, 23 January 2016

Notes from clsXlca 2015 Recognition discussion

Recognition

What do we mean by "Recognition"?

How would you like to be recognised?

Recognise contributions to a greater effort.

What does it look like?

(Individual Experiences)

    • Verbal
    • Specific, timely and explicit
    • Linked to org/communities goals

From whom?

    • Leaders giving thanks has certain gravitas
    • Peers giving thanks means something different
    • 'Members' giving thanks to 'Leaders' for doing leadership things is rare and just as highly valued.

Some people prefer their recognition to be private. Some prefer it to be public.

1:1 directed thanks is powerful; in person is often preferred within our discussion group; email, replies to public postings on mailing-lists/forums are all nice too.

How do we foster a culture of recognition?

Acknowledging code contributions and seeing them being used. Having patches merged in by that person who the community knows only merges the very best patches is a form of recognition, but it's not an accessible form to newbies who don't have that map yet.

Other people engaging with your code, either by linking to it, building on top of it, or extending it are forms of passive recognition that you're building something useful.

When a peer comes to you and says "that's a beautiful piece of work" (verbal, face-to-face worked. email didn't work for this person).

Recognising consistently good work is equally important as recognising someone raising their work to that level.

One piece of recognition is a project leader tweeting that someone made a strong contribution to a release and that was excellent.

If the recognition is written down it allows the recognised contributor to return to it at times when they are feeling like an imposter and get a boost.

Sometimes when you're the public face of a team or group, you will get the recognition for the work they do and you want to pass that on but don't know how.

One person liked it privately, really specific and didn't tend to return to the recognition.

Some times gifts work, not starbucks gift cards, but cultural artifacts (things that relate to the mascot), techie gifts and whiskey are all examples of gifts that work. Some people give team based swag (tshirts) which provides identity and recognition.

Relating it to personal or organisational roles makes it more powerful.

One way we recognise someone is by introducing them to other people and saying "This is $foo, they fixed that awful bug we had sitting in the tracker for weeks and they're awesome."

We recogonise people by attending their talks at cons and paying attention.

Some times recognition comes in the form of grant money for an org's goals or funding a specific development effort.

If you don't know how to recognise someone's work you can ask them what recognition they want. You may have to manage an unrealistic or impractical request/expectation here. [ASCII DRAGONS? ;)]

When you do your release blog/notes/files include everyone who contributed to the community in the thanks.

Code is tracked by SCMs. Translations are sometimes tracked by specific translation tools, sometimes by SCMs. Art assets in SCMs. Other contributions to the community tended to be tracked in peoples heads or in email archives (having project-by-project email aliases is useful here). There may or may not be a good technical solution to tracking these.

There are tools for tracking and reporting on metrics on who's replying to emails, irc requests and forums (http://bitergia.com/).

Some of the tools we use to track attribution don't work right for all use cases (author, reviewer/comitter, QA).

Metrics can't trump culture. There was talk about how gamifingy sometimes works but sometimes causes more problems. Fostering a 'culture of recognition'.

Discuss the ways in which you do your recognition.

Sometimes recognition is tied to the release cycle, some times it's periodic.

Recognition can lead to a feeling of belonging which can lead to engagement.

When people submit pull requests a bot replies on github with a 'we'll get back to you within X amount of time'. It was suggested that people who contribute to maintaining that SLA could be thanked.

Examples:

An org bought a bunch of postcards and at the end of a con told their attendees to write thankyous to people who couldn't be at the con and the org then posted them out.

One team member bought a bunch of hats which their projects mascot wears and sent them out to the core dev team.

We give commit access as recognition of work and sometimes maintainership as recognition of awesome.

Release notes, Authors files, commit logs.

Merging code is recognition of the contribution.

In Openstack, regular code contributors get ATC status which gives them voting rights on tech ballots for a year (there are other ways to get ATC status too).

Some websites put badges next to the user profile or the user name when they post.

"Shout Out Wall" (post it notes on a wall at cons to give thanks).