0009: Reduce Round Trips
As developer you will be very often communicating with other parties asynchronously. Typical examples of such communication are email, messages, as well as discussions in pull requests or document. It may take from several minutes, to hours, or even several days before you will get reaction to your actions back. If the other party is replaying once per day, you can be able to achieve only 4 iterations in a week. This is not too much.
There could be discussion like this in pull request or in chat and it could take days to get to the end.
- Alice: We should solve it differently.
- Bob: How differently?
- Alice: Approach Y is better.
- Bob: Why is approach Y better?
- Alice: Approach Y will help us in the future.
- Bob: How it will help us in the future?
- Alice: With integration.
- Bob: With which integration?
From this conversation we can see that:
- Alice has better of the knowledge of the system, its surroundings and its future.
- Bob knows very little about the system. *.Alice is busy.
- Alice is not realizing how much context is Bob missing.
- Bob is asking very short and general questions.
- Alice and Bob may be frustrated that there is no progress.
How To Get From This
If you are in this situation you have two different options:
Use Synchronous Communication
Synchronous communication has advantage of very low latency and therefore with the same approach you can get to the result more quickly. On the other side it has also several disadvantages. Knowledge that is transferred is usually not recorded anywhere, so it is lost for any other party involved. Cecile may show up and the same communication will start again. When Alice or Bob are not available this knowledge may be lost permanently.
Improve Your Asynchronous Communication
Main advantage of asynchronous communication is that we have record what was discussed and what was the outcome. If it was even public it can server as form of documentation. To be able to achive this both parties has to approach this with such goal in their mind. First step should be provide more context, motivation, and expected outcomes.
- Make sure that pronouns like - "it" or "that" - refers to just single items. If there is more of them, try to be more specific, to restrict it more. "It is not working." vs "Search form is not working."
- Answer on the expected questions in advance. "Search form is not working." vs "Search form is not working. I have tried to refresh the page and also multiple browsers."
- Be as specific as possible. "I was searching Google on Google.com. I have tried multiple browsers and all of them are showing 500 Internal Server Error".
Now this could be resolved quickly. Everybody knows that searching for google on google.com will break the Internet, so it is expected behavior.
|0008: Don't Be Blocker||Multitask With Caution: 0010|