3 ms·

One of the problems I often see is that when trying to explain one of the possible options, people don't understand it. When that happens, you try to explain it

One of the problems I often see is that when trying to explain one of the possible options, people don't understand it. When that happens, you try to explain it to them harder. Your explanation is then mistaken for pushing for that option. It's important to carefully navigate around this perception. People should understand that first you just want to be on the same page what your options are, and then discuss the best one.

rgrieselhuber 2y ago
Very true. It can be hard to properly articulate a position without feeling like you’re being too aggressive, I struggle with this a lot.
_heimdall 2y ago
My approach to that has always been to make sure I'm calling my assumptions with a possible option, usually that's either the use cases we care about or the scaling/infrastructure concerns. I learned pretty early on that its really easy for that context to be lost and that miscommunication go missed. Its so much easier to catch miscommunication early when a few extra seconds or minutes are spent calling out the context and assumptions that make one option best.
- hakunin 2y ago
  This is good sometimes, other times it risks losing the audience. Extra info works better when they're ready (i.e. asked for it). This is why it's such a difficult balancing act. You don't want to preemptively answer questions that people didn't realize they should ask yet.
  - Atotalnoob 2y ago
    I usually have my assumptions written, so I can flip to them quickly if there is any confusion
  - _heimdall 2y ago
    For sure, I was mainly thinking about later stage discussions where decisions like tech stack, architecture, or infrastructure should really be made. Early on its often all about use cases and users you're trying to reach. If microservices versus monoliths becomes much of a debate that early engineering is probably getting too far ahead of the product IMO.

rgrieselhuber 2y ago

Very true. It can be hard to properly articulate a position without feeling like you’re being too aggressive, I struggle with this a lot.

_heimdall 2y ago

My approach to that has always been to make sure I'm calling my assumptions with a possible option, usually that's either the use cases we care about or the scaling/infrastructure concerns. I learned pretty early on that its really easy for that context to be lost and that miscommunication go missed. Its so much easier to catch miscommunication early when a few extra seconds or minutes are spent calling out the context and assumptions that make one option best.

hakunin 2y ago
This is good sometimes, other times it risks losing the audience. Extra info works better when they're ready (i.e. asked for it). This is why it's such a difficult balancing act. You don't want to preemptively answer questions that people didn't realize they should ask yet.
- Atotalnoob 2y ago
  I usually have my assumptions written, so I can flip to them quickly if there is any confusion
- _heimdall 2y ago
  For sure, I was mainly thinking about later stage discussions where decisions like tech stack, architecture, or infrastructure should really be made. Early on its often all about use cases and users you're trying to reach. If microservices versus monoliths becomes much of a debate that early engineering is probably getting too far ahead of the product IMO.