The best way to organize your thoughts is to take some time to think, write, and make some reflections on it. This process, at least for me, has been increasing my understanding of some deep topics. This forces you to organize your ideas.

Bringing this to the tech world. I’m sure, if you are a developer, you’ve already faced some boring daily meetings, retros, and plannings…

The root cause for me is that before the meeting, nobody is taking time to think. And putting 7 engineers in the same room to do that at the same time, doesn’t seem a good idea!

My solution is always trying to push Async first. If the communication is stuck, the stakeholders are not contributing or something else. Then schedule a call, but at least now, you have previous documentation about the subject.

Here are some examples that I apply in my daily routine:

Discovery tasks:

Did you already hear from your team, that you have silos of knowledge? I’ve always heard this.

But for me, it’s ok, right? It’s not possible to split the whole knowledge between everyone. If you have a big picture of the problem, and your mates are following previous rules, good practices and so on. If some issue pops up, you will be able to walk and discover by yourself.

For me, covering the flaws in communication is the most important part!

Doing simple things, like. Hey guys, we are changing it here, this will take X days, my architecture idea is this one, and I have some doubts to cover! Is someone against it?

By that, you put everyone on the same page! As I said before, to have an engaged team, is to have a team that knows what is going on, in the big picture.

Retros

A common practice in environments that use Sync, is that your mates will wait until the next meeting. I mean, why not expose what you are feeling when the issues show up? This is the most effective way to fix something, you don’t need to wait 2 weeks to expose it in your Retro.

Why not create small retros between the guys who worked on some task, pointing out the pros and cons? Write a document, and show it in a meeting! The thought behind this approach is:

Give time to your engineers, they should be able to absorb and reflect by themselves. Do that in a meeting without previous mulling, it’s a waste of time.

Dailies

This for me, is the most inefficient one, imagine your leader, that is taking care of a pile of work. What is better? Some bullet points in her/him chat, or 30 minutes per day of shitty talk?

If we understand that as developers, we need to give some forecasting. Being clear about problems and blockers, the work environment will be pleasant.

A simple thing like:

• What I did yesterday?

• What I will do today?

• Am I blocked or need somebody’s help?

If your mates send it every day, and have a meeting at the end of the week, doesn’t sound better?

Or some notices during the day, like, hey I’m stuck with X, but I pretend to come back at 4 pm.

This is good communication! Be clear and give your mates some forecast about what you are doing.

The end

For sure, if you are in an environment that is too hard to change, these ideas won’t fit for you. However, I had the pleasure of being involved in teams and companies that use these approaches. In the end, This approach is an attempt to be more quick. To give more autonomy and responsibility to your coworkers and put everyone on the same page.

It’s the same to say. Hey dude, you are the leader, please be clear about the things that you want to say, and take some time to think about it.