4 ms·

The more important and general wisdom: know your audience. You will sometimes have clients with deep technical backgrounds that expect a sufficient level of det

The more important and general wisdom: know your audience. You will sometimes have clients with deep technical backgrounds that expect a sufficient level of detail to have any faith or trust in your solutions. You need to be able to tailor your communication based on the situation and the expectations of the audience in question. This is never binary and can be especially challenging when you need to communicate to multiple people at the same time that each require different levels of detail.

deleted 3y ago
[deleted]
AmIDev 3y ago
This is something I struggle with. I have a weekly meeting which includes TL, Manager, PM and sometimes Staff engineers, Data analysts, Managers of downstream teams etc. I try to keep the details to the lowest denominator, which usually means mentioning what the problem is and what the proposed solution is in few lines. But eventually someone will ask for more details, and then the conversation veers off to technical discussion that I am sure the PMs and Analysts don't understand.
- kupopuffs 3y ago
  tech design meetings shouldn't have product. and if this is a demo, then it should only really require stakeholders. if the meeting is for product to share their vision or requirements, save the tech talk for later its very tempting to get into the weeds of things, but this can be "parking lotted" as the kids say
BiteCode_dev 3y ago
Indeed, but this general wisdom is too vague to be useful on its own. When I was young, I heard it many times, and couldn't make anything from it. What's the audience exactly? How do I know them? Once I know them, what am I suppose to do? And all that stuff is contextual, so what are we talking about really? When learning to negociate, knowing your audience is a very different thing than when trying to teach. Very few people are able to pull it off accross fields. So I decided to write an article that targets a specific case with a concrete application and examples. This would have been more useful to me back then.

deleted 3y ago

[deleted]

AmIDev 3y ago

This is something I struggle with. I have a weekly meeting which includes TL, Manager, PM and sometimes Staff engineers, Data analysts, Managers of downstream teams etc. I try to keep the details to the lowest denominator, which usually means mentioning what the problem is and what the proposed solution is in few lines. But eventually someone will ask for more details, and then the conversation veers off to technical discussion that I am sure the PMs and Analysts don't understand.

kupopuffs 3y ago
tech design meetings shouldn't have product. and if this is a demo, then it should only really require stakeholders. if the meeting is for product to share their vision or requirements, save the tech talk for later its very tempting to get into the weeds of things, but this can be "parking lotted" as the kids say

BiteCode_dev 3y ago

Indeed, but this general wisdom is too vague to be useful on its own. When I was young, I heard it many times, and couldn't make anything from it. What's the audience exactly? How do I know them? Once I know them, what am I suppose to do? And all that stuff is contextual, so what are we talking about really? When learning to negociate, knowing your audience is a very different thing than when trying to teach. Very few people are able to pull it off accross fields. So I decided to write an article that targets a specific case with a concrete application and examples. This would have been more useful to me back then.