I was listening to the Post Status podcast this week where Cory Miller and David Bisset discussed creating time for play within work. I write this not thinking they were advocating for what I disagree with, but the podcast inspired me to share my perspective.

Creating space for play absolutely resonates; we learn through play and grow as a child through it – play stages are a critical part of human development and even used in many therapeutic practices. However, I think aspects often get overlooked in the enthusiasm to create a space for play, those of cultural and wider inclusion. As a result, those spaces become exclusionary and sometimes daunting to participate in when the opposite was intended.

A set time, a set space where everyone is designated to be social, can be problematic. First up, if you have a team across timezones, someone will be suffering either bleary-eyed morning, juggling child feeding times or needing sleep. Second, culturally being told to do things by your boss can impact heavily. Even if it’s fun, you might think there’s a performance measure aspect here. Depending on your language barriers, the activity also might be incredibly stressful.

One approach to deal with time zones is to split the team or group into sub-teams to play. This is almost even worse at times. This likely sees certain people with some leads and others with none. It can make people feel they haven’t got time with some and if you regularly do playtime like this, it forces divides. I would strongly advise avoiding splitting people ever like this.

Remote work enables people, so forcing a set time to do anything can remove some benefits. What if that person has a medical condition which remote work allows them to work around, and they have a flair for that hour of designated playtime? Sure, they can miss it, but they both might then feel guilt, and they missed out on bonding or, even worse, some communication shorthand that others gain through that activity.

Another aspect to understand is what work means to many. Being able to play within work is a concept not all cultures or mindsets will find natural. If your team is diverse across timezones and types, you have to understand each person probably comes to play differently as an adult. Children are open to play; adults get more closed the older they get in many respects unless they practice it or are given space. This is shaped by their lived experiences, their type and the culture around them. You also need to have a space of trust to play; as a leader, you can assume trust where maybe others don’t feel it all the time.

Our brains have different experiences of social play. Some might have been bullied when younger, so picking teams even is a trigger point for them; imagine how they might feel if a team picking happens and gets picked last. Or if they do badly in front of their team and now get memories of that happening when they were a child. What for some are incredible social experiences aren’t for others. This needs to be considered in whatever activity takes place. Give options for participation.

Don’t get me wrong, I am not against play space or even designating and setting time for it for everyone. It can work in several situations very well. I actually think it should be a part of work constantly. My biggest point is that play space should become a space of exploring and also constant.

One other aspect of this is that it needs to start slowly, be earnt. I honestly think if you can start with instantly it working, that’s incredible but rare. You have to probably start by setting some boundaries, which I know goes against the idea of true play. This is about safe trust-building though, here are some recommendations:

• Allow everyone to set the time to work for them.
• Set themes for exploring as a leader: this removes the worry from others. Mix in a combination of work and learning a new skill.
• Allow space for simply sharing. This is far easier for many than play and gets them learning to trust. Always give alternatives for example just saying share a book you’ve read that month and if someone struggles to read every month – that’s a worry. By saying ‘share a book, film, piece of music or something you liked this month’ – suddenly that’s less stressful.
• Create a devoted playspace where people can share things as they create async. This lets everyone have comfort and nobody gets put on the spot in a meeting. Sharing can be the start of play and is often overlooked as a starting point – it’s a key stage in play for chidren.
• Encourage collaborative play but find ways as a leader to make it async. If you do this right you can even combine to increase communication across roles/areas.
• Start using play formats in meetups/workshops and retros. By incorporating play thinking closely into work practices it says to everyone that play is part of working here and welcome.
• Always set a start and end point if you set play topics. Open and close the designated play even if async.
• Your experience as a leader or person that sets the play won’t be the true measure, so open all your senses to others.

As people learn to trust, increased connections will be made, and likely self-organised play will happen. You should leave space for suggestions for play because that is when the magic happens when those playing start directing it.

There are various types of play; lean into those. I don’t see play just as a set time to play an online game remotely. I like this definition to start exploring a bit more:

“Play is a free activity standing quite consciously outside ‘ordinary’ life as being ‘not serious,’ but at the same time absorbing the player intensely and utterly. It is an activity connected with no material interest, and no profit can be gained by it. It proceeds within its own proper boundaries of time and space according to fixed rules and in an orderly manner.”

Johan Huizinga

Play is magic; the effects of someone realising they can safely play within work, on their terms, will be felt not only in how much better they will work but also in their improved relationships and ideas. However, it’s not something instant. The space also needs curating, tending and nurturing. Play has a lot of benefits, so it’s worth taking those considerations.

Sketching state is where everyone in product creation is collaborating enough and sharing enough that sketches work. All too often, spending lengthy time coming up with a complete prototype can be far too time-consuming. Passing pixel precision backwards and forth limits the flow and stops that spark of creativity. However, it’s not a state that doesn’t need evolving as a team and careful tending to as a designer.

I want to be clear; there is a place for almost every form of presentation you can think of for a design concept. I am not talking about stopping using whatever works for you. However, getting to a position where you can share early, sketch often and be open about those early ideas – that’s gold for any creative. It’s not something instantly achieve, though and takes work collectively.

I find myself when joining a team testing the waters with how ‘sketch’ I can go. This is an excellent thing to do; it allows me to see where communication is, where collaboration needs to grow. By doing this type of testing, I can refine and adjust my communication, learn where I need to improve and what communication style works for my joining team. One size never fits all when delivering design – that’s why we have a toolkit. I also use sketching as a tool to test during later team development as we grow.

I also think it’s important to frame that sketch doesn’t mean half baked; you still should have a solid idea to share, it should be at least complete as an idea sentence, your visual though might be very raw. Sketching is valuable short-hand communication and key as the product grows and iterations happen rapidly. I encourage not just designers to talk in sketches if the space is comfortable for that – it takes trust across roles for that, though, and safety has to be at its peak for everyone.

Design is as much about judging the way you can deliver the message as delivering at times. I don’t get it right all the time; nobody does. It helps if you have a range of methods to try. I haven’t found one process that works for everyone, although you might have different outcomes. My processes are chameleons, but the one that consistently fails are words alone.

Similarly, talking in flat files passed as complete packs to make, that never works – signoffs lead to silos all too often, and frequent conversations need to happen as work is going on. The design needs to be iterative and respond to the actual product work, not remain stuck on ice. This is actually where having a design system that can prototype sketch comes in useful.

Being in a sketching state as a team means a high level of collaboration; it’s a strong flow of trust and space for each member to bring ideas openly. This is powerful to create in and one personally I seek constantly to create within.

So you want to open source your project for others to contribute? That’s great, but where do you start? With a few things to consider, you can start on the right path from the start with contributions and avoid some of the common first step problems. This guide is a minimal viable opener if you will – a start.

Have a welcome

If you think of the project as your house, welcoming someone in is great. Even better is the tradition of a welcome mat and then sitting someone down, making them feel at home and give them a cup of tea. Your project version of that is solid documentation (no matter where it’s hosted). This sets the tone of your project, the voice many will hear before they even start contributing to it.

Provide signposts to contribution

If you want contributions, be sure to show how and where they are wanted. It’s one thing to say ‘all contributions are welcome’, but that’s open-source theatre because honestly, it’s likely not all are in every area as welcome as others. There are always more areas needed than some. Highlight these and make sure someone gets off to contribution success from the start.

Document everything possible

I’ve hinted at this with my previous points around a welcome and signpost, but you also need to have documented everything possible. From code to vision and everything possible – ensure there is something written about it if possible. You might want to have documentation as a contribution, but if that contributor has to guess what you were thinking, that will not be someone who will stay around a long time. Give everyone a start with some basic documentation.

Show the small ways

By highlighting not just the big things to contribute to, but the little wins – someone can dip in and support right away. Show how to test, report a bug (using templates to make easier reporting is fantastic) and show the level of commitment of fixes. If something requires a certain skill or understanding, clearly mark that also – it helps people focus where they are going to be the most effective.

Say thank you

The biggest thing you can do to someone contributing is to say thank you no matter what size that contribution is. Recognise that contribution, say thank you. If someone takes the time to contribute, make sure you engage with them. You wanted them to, so don’t leave them contributing without interacting. That’s a lost contributor and one that will rapidly find another project.

Include and recognise contributions

Opening your project to contributions isn’t a checkbox. It’s not something to do if you genuinely don’t want to accept and merge in contributions. Otherwise, it’s performance, not actual, and you are unfair to people who try and contribute.

Beyond including, recognise those contributions. If you have a release, put those contributors are in front of it, celebrate them. They have helped you make what it is; you wouldn’t be there without them.

Be open about roadmaps and releases

If you have contributors pretty soon, you need to be open about plans you have for your project, goals and releases. I believe you should have at least a project roadmap table somewhere—ideally, open project boards and a roadmap. I like the way Github do theirs.

Opening your project up can be incredibly rewarding, but do it respectfully and then who knows what incredible contributors will join you on the adventure.

When design is mentioned in open source, it’s often as a scarce resource, one yearned for or maybe hasn’t had an easy time. I think this might be problematic and needs changing. Designers can use open source projects as a growth opportunity and learn in a space that is accessible. I would go as far as saying it would benefit every designer from being in that space.

Designers need open source projects just as much as those projects need them. These projects have the growth opportunities many designers crave and need to develop their portfolios and prospects. They can provide ground for a budding new designer, a way to shift from one focused discipline of design to another.

Finding a junior role in design right now is not the easiest thing; it’s even more complicated if you live in a location that’s not a city or country that’s not where the most prominent companies are. Remote works, but that is often meaning a lot fewer junior roles – a problem in itself.

Open source projects allow a designer to often learn by doing, really fill their portfolio with meaningful examples and often without the hurdle of interviews that might not even be in their language. It likely even has onboarding in multiple languages or contributions days (even remote) if it’s a long-standing project. A newer designer can work alongside seasoned designers, growing in skills through observing and collaborating. That’s a powerful gift provided freely within open source projects.

A designer in open source gets on the ground practice in feedback processing. They are constantly the advocate for the user and learn to collaborate with other roles by doing. They are often also opening up to exploring far more areas than they might in their daily roles to see where they want to grow, even where they need to develop. Teamwork is a crucial part of any open source contribution, so that’s an essential skill taught, along with remote collaboration.

Should you want to, you can move into operational roles such as team rep or lead. You can even look to lead releases: something beneficial for any designer looking to explore that type of role as a career direction. The types of design being offered are also incredibly varied in these projects, from product, visual through to marketing and much more.

The time has come for us to change our perspective on open source and not focus on highlighting how much we need designers, but show what the designer can get from working in open source. Most projects are focused on inclusion efforts and trying to create better projects, so the time couldn’t be better to join. You also don’t just have to stick with the big ones you might have heard. You can move around projects, go where you want. Perhaps there is a tool or resource you use that could do with your help; that’s actually how many of the more significant open source projects evolved. Open source has grown me as a designer and it can grow you.

Words matter; we put labels on things, we put labels on each other. Those labels lead to judgements. The ways we judge what capability someone has or hasn’t in something technical only tend to lead to harm, I’ve found. It’s a way to limit before you even know someone, and that’s one way to block ourselves rapidly from a potentially beneficial experience.

This tweet inspired this post:

https://twitter.com/joshsimmons/status/1417694331532570624

I’m a designer who can code, hardly a rare creature. However, I’ve seen so many times throughout my career where labels of non-technical were attached to me and boundaries were drawn with verbal chalk where I shouldn’t go. Anyone around any time in the software industry might have more than one discipline: designer/writer, design/development, business/systems. There are so many potential variations because you gather exciting knowledge. That is what makes everyone more valuable as they travel their career.

The most significant impact of labelling wasn’t just limiting my worth because it did limit my value in my role. What it did was also end up me mirroring that behaviour. That’s a part of human nature; this type of role dividing is infectious. You are limiting resources, so someone will clutch to the little they have because we are human. I was feeling threatened and devalued, so I responded from that place and mental state. It’s a cycle that you learn and then take to the next role – it goes around and around. It’s a cycle we, a product making industry, have to stop.

By using that label, you impact that moment but also future moments. There is, for example, psychological proof this happens when using the term bully to someone or labelling someone’s mental diagnosis. It’s why incredible care is taken before confirming the diagnosis, which can be a relief to many but, when wrong, a dangerous situation. Limiting someone in this way is potentially dangerous because if you say to someone they aren’t technical, they might assume that is always the case and never reach their potential. Historically, people were told you could be artistic or scientific, left or right brain; women can’t code. As someone that grew up in an age where that happened (it’s not that distant), experiencing that, anything we can do not to repeat that I welcome. Collectively moving beyond this isn’t always easy as it’s ingrained, but it’s gratifying to do so.

Another part of this cycle that’s also just toxic is the resume and background boasting. Nobody should have to prove what they have done to be heard. It means you end up falling into the trap of proclaiming your ‘technical’ or proving. This limits just to the role of development, ruling out other technical backgrounds, and that’s a massive part of this. Technical isn’t and never was just about code. This myth of the divide, the gatekeeping, the ‘us’, and ‘them’ isn’t your product because every person goes into it.

I’ve seen this the other way around, too; I worked a long time ago in development roles and was told ‘just technical’, so I couldn’t comment on the experience. That discounted my background – again, words matter, and it wasn’t using my total value. No matter which angle you come at this from, it hurts. Most of the reactions you see are from hurt people who have learnt that hurt because words matter.

Often you see in a space where this happens; walls go up around the disciplines. You will see increased gatekeeping, process creation can often escalate, and people frequently across the company will be on high alert to prove themselves. The reaction you see is a symptom of people hurt; they are wounded, not united. It just took language – language is that powerful. This space is ripe for other us v them behaviours. All they need is that one fertile ground of divide, suspicion of the other, and you instantly have combative thoughts in your team, and inclusion is more brutal to nurture from that point.

If you take it from a business perspective, it makes no sense to have every skill someone can use. You hire someone for being the incredible person they are, not to use a small percentage. Similarly, more robust products come from allowing more disciplines equal input. I’ve seen remarkable changes come every time this opening; this welcoming approach to creation is at heart. Amazing things happen when nobody feels they have to prove themselves or each decision is a round of combative discussion where proof has to be seen of validity to join in. You don’t want to block any possible revenue stream as a business, so why stop creation streams inside your production process?

Perhaps the next time you go to use the word ‘non-technical’ to describe someone or ‘non-coder’ and even ‘non-developer’, pause. Do you even need to label? What is that doing to them? Does it help move that conversation on? Are you doing it because you’ve learnt it? Am I saying it because someone once told me that? Perhaps leave the label to the side no matter what role you might be labelling and see what a difference it makes to how you feel – I know I’m going to try that for a while to see how it fits. None of us is perfect, and we all do this, so we need to change our mental models collectively.