Preface
You are invited to a meeting. There's no agenda, no subject, just an invite. It's not optional, you're required to be there. You can see the participants: a product manager, someone from business and a designer. You can't prepare. You feel lost and hope for the best.
You enter the video-conferencing channel. The host starts the meeting. After 29.5 minutes of listening, you are sure that this is about a new project. The product manager and the business-guy are having a debate about the requirement, the initial idea. You and the designer are listening muted. You have a gut feeling, that the designer didn't receive details earlier either. The meeting ends without action points. You feel that your time was wasted.
How could all this be done well? What can the developer do to ensure that if the organisers are not properly prepared, you don't waste time? How can you help each other to get the best out of it?
1. Avoid assumptions
Continue with the above situation. Let's face the truth: the meeting was a failure. Why is that?
- First of all, every participant assumed that others will have an exact topic to talk about.
- The participants hoped that the others will save the day by thinking during the meeting.
- Some hoped that they can get away with the whole meeting, if they remain passively silent.
So what can you do?
2. You are a respected member of the team - take advantage!
Developers are in high demand. Take advantage of your privileged position. Point out that you can't be effective if other actors don't get the attention they deserve - in time.
- Without a well-defined business requirement, a UX researcher can't conduct interviews with the right interviewees.
- Without the proper data (and its analysis), a designer can't create logically operating flow with the best UI design possible.
- Without clarification of acceptance criteria, quality controllers can't come up with the right test cases and they'll forget about the potential edge cases as well.
- Without the above, you won't be able to provide the proper solution (e.g. if you know only that they'll need a data table, you won't necessary think about scalability).
3. Clarify and force async collaboration
Every time when you feel that expectations are not set, be the one who points it out. You'll save time not just for yourself, but for the team as well.
- Ask for clear agenda when it's missing from the invitation.
- Check the documentation and comment if possible: if something is missing or wrongly stated.
- Push async communication: every member has different biorhythm - if you're awake and effective during the morning, it doesn't mean that others can follow you instantly. In addition, they might want to spend time with their families instead of having a meeting that could have been an email. Respect the others' time.
4. Avoid toxicity
The company culture is an important factor when accepting an offer or even avoiding another. Once you feel respected, accepted and valued, you're much more likely to stay in a job for the long term. You'll take an interest in making the product you're working on a success, as this will make your employer feel respected - and at the end of the day, that means a long-term, secure and stable environment for you. It's a mutual collaboration that benefits both parties and is worth developing.
That's why it's a good idea to choose a style of communication where your opinion is listened to and sought again. Instead of purely negative comments, make constructive suggestions when you disagree with an approach. Point out how a problem could be solved more effectively and nicely.
5. Learn how to say no
Respectful, supported and reasoned opinions are more likely to be listened to by all participants, especially if they reflect the views of others. Even if you say 'no', if you can prove your point and support it with strong reasoning and examples, you'll help others to accept your views. Saying 'no' in a strategically important situation or 'stopping' at a certain point can save teams and project from their own mistakes.
If you are able to combine your own professional suggestions with the interests, suggestions and guidelines of others, you will have room to extend cooperation to a much higher level.
6. Push out of balance
Let me share two stories. Both stories are about stakeholders being in a kind of status quo and how they are pushed out of it for the sake of the project.
A few weeks ago, I was involved to a project. The developers told me about the project and the requirements. It seemed to be a simple redesign. I finished the mockups, handed them over, developers were happy. A few days after, I received notifications about the PM commenting in Figma. Last week I was invited to a meeting by the PM, the subject was the review of the mockups. I could see another unknown participant. I asked the PM to invite everybody who was involved, because I feared that information pieces would be lost otherwise.
Let me reveal the fact, that the meeting that I described in the preface was the actual happening that inspired me to write this article. I was listening to the PM and the business stakeholder debating on what is actually needed instead of what I've done previously. I was listening to them for half an hour and I could not take it anymore. I suggested to the PM and the business stakeholder to discuss all the details in a smaller group and when they think they're ready, provide a clarified specification offline. After everyone read it, we can collaborate asynchronously and decide how to move on - until then, it's just a waste of time (and money). They accepted my reasoning, now we're waiting for them.A few months ago, a top-level manager asked our team to create a certain dashboard for our users. Business stakeholders started to list buzzwords what's needed on that dashboard. Luckily, I was present during that meeting. I asked them to invite the UX researcher so that she'll understand the requirement and will be able to conduct interviews. I also suggested that I'd create an interactive prototype, so the interviewee would be able to imagine a certain approach. (This has the biggest benefit of having instant feedback about what the users do and don't like at first glance.) To be able to create that prototype, I needed some inputs. I reached out to the UX researcher and developers who worked with similar dashboards. I knew that I won't be able to provide the best solution first, but I wanted to force the participants into a situation where they have no other choice, but to think about what is actually needed. This is highly recommended, when you've no specification available. We're having two 30-mins meetings: first, when they shared their insights and suggestions, and the second when they provided their feedbacks on the mockups I created. During this second session, we'd polish it enough, so that the UX researcher was able to use it. I was present on the user interview and listen the immediate feedback: struggles, points that need clarification and instant positive emotions.
My point here is that don't just put the problem on the table - bring some ideas how to solve it. Even if it won't be perfect, it will be good enough to force others to start thinking.
Prologue: a few words about psychology
The word 'psychology' comes from the Greek words 'psyche' (which means 'soul') and 'logia' (which means 'observing'). What I described above is exactly the same. What you do when you react to the actions of others during work is a reflection of what you understand from the resonance of others' soul.
In other words: it doesn't matter what role you hold in a certain team. What matters is how you can collaborate. This won't just affect on your actual status and position - it'll have a strong effect on what you become and how you grow professionally.
Do you like to think of yourself as an expert? Act like one. This way you'll support your team mates, the processes, and at the end of the day: your behaviour and advices will help to run everything smoothly.
Top comments (0)