3 ms·

The best advice I got early in my career on this topic was: “Nobody serious is going to take you seriously if you give one option as the ‘way it has to be.’ Eve

The best advice I got early in my career on this topic was: “Nobody serious is going to take you seriously if you give one option as the ‘way it has to be.’ Everything has trade-offs, you will be much more effective as a communicator if you list a few options, along with their trade-offs (and be honest about these). You can even have your preferred / recommended option but it also must come with trade-offs.”

hakunin 2y ago
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.
dpacmittal 2y ago
I do this instinctively but I feel like I'm coming across as confused and unsure.
citrin_ru 2y ago
Well, you mileage can vary. I see trade-off almost everywhere but many managers are not exited to hear about trade-offs and want to get a perfect solution when you don’t need to sacrifice anything. Though it is not as bad as a manager who already made a decision ignoring trade-offs of different options.
philwelch 2y ago
Unfortunately there are a lot of non-serious people in the industry.
dude187 2y ago
That's how I give advice and it can be a huge struggle when working with people out of their element, or in a job they frankly didn't earn. It's really the only way a productive design conversation can go, but those who can't contribute from their side of the fence will get frustrated. Saying things like "you just need to tell me what to do". On the flip side, those who think they know better will have pretty much already made up their mind. Which makes things even worse if they don't know better, but for the competent ones this is the easiest and most effective setup of them all.

hakunin 2y ago

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.

dpacmittal 2y ago

I do this instinctively but I feel like I'm coming across as confused and unsure.

citrin_ru 2y ago

Well, you mileage can vary. I see trade-off almost everywhere but many managers are not exited to hear about trade-offs and want to get a perfect solution when you don’t need to sacrifice anything. Though it is not as bad as a manager who already made a decision ignoring trade-offs of different options.

philwelch 2y ago

Unfortunately there are a lot of non-serious people in the industry.

dude187 2y ago

That's how I give advice and it can be a huge struggle when working with people out of their element, or in a job they frankly didn't earn. It's really the only way a productive design conversation can go, but those who can't contribute from their side of the fence will get frustrated. Saying things like "you just need to tell me what to do". On the flip side, those who think they know better will have pretty much already made up their mind. Which makes things even worse if they don't know better, but for the competent ones this is the easiest and most effective setup of them all.