Only one thing can be the most important. If we want to align a workshop well, aligning it for one thing, and nothing else, is the easiest. A workshop has limited time, so the scope must be limited. Decide what the most important outcome is for the workshop, and design it fully for that outcome.
Everyone is important in a workshop. If the purpose is learning, each participant needs to get a chance to grow. For workshops aimed at creating or exploring, the views from everyone are even more crucial. It is important to have a structure that works for extroverted and for introverted people. One way to do that is by using exercises that let people think on a topic in multiple ways, some of those can be found among the liberating structures.
Guiding towards the purpose, and enabling participation, is done through structure. This post is about creating structure in a workshop
For a workshop to work as planned, you need to be able to complete all steps. Some workshops can bring value when half-finished, but most need the conclusion and some make things worse if left half done.
The workshop needs full focus. If the participants lack information, the facilitator has to have it at hand; otherwise the schedule will be disrupted. Try to anticipate what will be needed, or plan for breaks long enough so that missing information can be found.
The last, but not least, part is trust. The environment has to be psychologically safe, and the facilitator must be trusted by the participants. Trust can be cognitive or emotional. The important part is to have a mandate to lead the workshop, and that everyone else feels safe to participate. You can read more about psychological safety here.
]]>If we want people to learn new things, collaborate with an open heart, and challenge the limits of their capacity, we do that by creating a safe and nurturing place for them.
The way out of the comfort zone is to have a comfort zone to start with. Make people feel so safe that they get bored and start creating, so cherished that they dare make a fool of themselves, and so relaxed that all energy go into the task at hand.
]]>It is not your fault.
Software causes stress in the workplace.
The stress can come from things breaking down unexpectedly, like projectors not starting, audio missing in the video conference call or the e-mail draft disappearing as you refill your coffee.
There are also the thousand cuts from the paper free work place. Interfaces that are clunky, dropdowns with a thousand options, where the most common is the last. Forms demanding you to type in the same information three times and then complains about the format. (Perhaps by erasing everything you entered in so far.) Information portals with unreliable search and no predictable structure. Not to get stared on permissions to add or change information (or structure).
This text is about coping with what you can not change. Part two is about eliminating the source of the stress (bad software).
Software should never make you feel stupid.
When the printer throws a tantrum or an app suddenly restarts, the responsible people are:
Unless you are on that list, it is not your fault.
Software doesn’t have to be like that. The industry knows how to create intuitive interfaces. There are processes for writing reliable software. User research exists, just not enough. You deserve better software. No human is non-technical, it is the technology that is inhumane.
Reporting issues with software has two benefits. If the software organisation is good, it will use the feedback. For organisations too immature to appreciate it, at least you can use it to let out some steam. Put your frustration into precisely worded descriptions and screen recordings showing the problem. Be polite, since that will help the organisations who welcome it and annoy those who don’t.
If the workbench has the wrong height, or the knives are blunt, you can not expect the best results. The same is true with IT. You have to adjust the expectations on your staff accordingly. (At least until you are able to fix the software.)
The cognitively ergonomics of a workplace are as important as the physical ergonomics. Software that is hard to use and/or unreliable, will affect the work, regardless of the attitude among the employees. It is biology.
Software developers also suffer from IT-related stress. No one is too clever to benefit from easy to use software. If you are taxed by flaky tests or buggy editors, know that you also deserve good interfaces and reliable experiences. You are not less for wanting to work smart rather than hard. If you struggle with getting software to work, it has nothing to do with your aptitude as a developer. You don’t have to be smart to make someone else feel stupid.
If you are a manger, or a role model, in IT, don’t idealise fire fighting. Acknowledge when infrastructure and tooling are slowing you down, and celebrate the canaries in the team.
]]>Not only will anti-work make life harder inside the organisation, it also leaks into the surrounding world. Anti-work pollution!
There is a lot of literature on the topic targeting the IT-industry. The Phoenix Project both describes where it comes from, and parts of what we can do about it. Preventing anti-work is also something a Technical Coach helps with.
We want to minimise anti-work to be more profitable and a better work place. We should also pay attention to what our anti-work does to people outside the company. An organisation that fails to prevent anti-work for its employee, will also cause anti-work for its customer.
It might not be that the entire system is down. It is enough that there is some kind of unavailability or error, that will ask more of the customer than they planned for. Restarting apps or devices. Forms that clear all entries on a single error. Data that don’t sync properly. Having to wait or reschedule your task for another time. And it is not only software that manifests it, though it is often software involved. (Or better software could have prevented it.)
Ordered food that only partly show up might not seem like a biggie, but it might also cause the anti-work that blows up something really important for that individual at that time.
When the anti-work hits your life, instead of your work, we often lack protective systems. The nuclear-family team of two, or one, doesn’t have the redundancy of an IT-department. If the service you build is of any use, or importance at all, it hurts when it fails the user. It might only be a paper cut, but could be one of thousands in total. It will probably hit harder for people with less privilege to start with. As a system, a society, we should all be more careful with each others time and energy.
Don’t be an anti-work polluter! Take care to build quality software!
]]>Psychological safety is found to be the key to why some teams benefit from diversity and others don’t. A part of being an underestimated person — someone who most of the time is the “diversity” of a team — is sometimes entering worlds where you feel you don’t belong. In a team without psychological safety you do this by sacrificing your voice. Just like the mermaid, you then lessen your chances of actually getting to stay and be recognised for what you can bring the team. Research shows that underestimated people are extra sensitive to the presence of psychological safety. One of the factors for predicting successful teams is that every voice is given the same space. In a psychologically unsafe space the underestimated people act as the canaries in the coal mine. They get silenced first. Therefore, only psychological safe teams can benefit from diversity.
Just as the little mermaid could not get her voice back, there is no way a single person can “become psychologically safer” or fix the issues in a team on their own. If those with strong voices want to utilise the full potential of their team, and listen to everyone, they will have to do a lot of the work. It might seem unfair to expect the prince to do the work when it was the witch who did the bargain with the mermaid. Life is not fair. The prince has power the mermaid has not, regardless if he asked for it or not. With great power come great responsibility, regardless of how the power is granted.
It might be easier to just keep the mermaid mute and pretty, dancing to please the prince as in the original story. But that will not build a great team. And even though the original story of The Little Mermaid is said to have a happy end, it does not include the prince. In STEM that is sometimes referred to as “the leaky pipe”, when the group grow more homogeneous as people that are underestimated leave.
So if you are underestimated and mourn the loss of your voice — have some hope. The magic word is psychological safety. It is the key to succeeding at all knowledge work done by a team. Awareness of it will grow. If the pain is too big, remember that it was Disney that made the happy end “to live happily ever after” with a prince. The original mermaid ended up spending 300 years with her sisters before going to heaven. Find a place that do you justice.
And if you have a mermaid or two on your team, and want to hear what they have to say (not only watch them dance until they leave), read up on psychological safety, and then act on it. Diverse teams have a competitive advantage if all voices are given equal space. And no one should have to lose their voice to get access to the software industry.
]]>