🫂Working with Different Working Styles

Overview

We live our mission and values everyday, and you should too as a community member. We are a community of learning and growing individuals working towards access to quality leadership development and teamwork development. Be conscious of how you are communicating with others. Do not make sexual comments to another community member. Do not make jokes towards anyone that may discuss their background or identity. Please report any violations of code of conduct through the processes we have in place. Read more in ourCode of Conduct and Anti-Harassment Policy.

Being You and Respecting Others

Tech Fleet team members come from all over the globe. They bring different lived experiences and perspectives. It is important that we recognize and respect everyone’s way of life. Every member of our community should feel a sense of belonging. Everyone should feel free to challenge decisions, speak out, and communicate their boundaries in their team environment. Using ‘they’ when a team member has not explicitly defined how they want to be identified is one example of building a healthy work environment. Likewise, you should feel comfortable communicating your personal preferences, whether it be name, gender identity, working boundaries, or anything else.

Structure your meetings and tasks in such a way that every team member is able to play to their strengths and lean on the team for help with their weaknesses. One way to do this is by communicating directly and clearly as much as possible, avoiding innuendos, sarcasm, and implied/unspoken statements if there is any risk of being misunderstood. Your team will benefit greatly learning about your unique strengths and challenges and how accommodations can improve the team's output as a whole.

Everyone excels in different kinds of working environments. Some of us enjoy working collaboratively in a synchronous environment, discussing thoughts and ideas in real time. Some of us feel more productive doing the thinking on our own and sharing our thoughts in Slack or through a comment within a document. It is up to the collective team to discuss needs and desires, make compromises, and ultimately determine what a working environment looks for them.

Asynchronous Working

In the perfect world, everyone will know exactly what they need to do at any given time and provide their deliverables in a timely manner, without ever having jumped on a call. Unfortunately, that’s not the world we live in, but that doesn’t mean it’s impossible to work outside of a call. Async working requires planning and delegation, but is a great way to maximize the amount of time and attention a task is given. Teams should decide what level of async working they feel comfortable with and ensure that is the default for the duration of the project.

💡 For example

let’s say that I’m working as a Design Apprentice on my team project.

The design team has just had our weekly meeting to discuss action items for one of our tasks. I’ve volunteered to take on the task of moving one of our mid-fidelity components in our Figma design system into high-fidelity.

During my heads-down working session I’ve noticed the component I’ve been assigned doesn’t use Auto Layout. I think it would be beneficial for the high-fidelity version of that component to incorporate Auto Layout but need input from the team. Without that input, I’m blocked from moving forward.

In order to unblock myself without organizing a synchronous working session with my team, I can send everyone a message in Slack explaining my blocker, what I think we can do, and my desire for input from others. Once I’ve received that input, I’m unblocked and can continue completing my task.

Synchronous Working

Some discussion can’t be hashed out over Slack and need to be addressed synchronously. You might find yourself discussing something asynchronously with team members, yet after two or three exchanges back and forth, no decision has been made. In this situation, a synchronous session may be warranted. Sync sessions can also manifest in the form of sprint planning, weekly team sessions, and client demos.

💡 For example

let’s continue with the scenario from Asynchronous Working.

I’ve sent everyone my message with the expectation that I will be receiving straightforward feedback on direction. A few exchanges later, I realize some of my team members have gone ahead and used Auto Layout on their components, and others have not. We’re split on how to move forward and we’re no closer to preparing our deliverables for the sprint.

At this point, in order to unblock myself and everyone else, I decide to call a short meeting. We can use this time to discuss the pros and cons to using Auto Layout. At the end of the meeting, we decide Auto Layout is the way to go. I’m unblocked and off to the races.