3 ms·

> On a separate(?) topic, a lot of tech organizations seem to be fond of saying they want to hear all ideas and judge the ideas on their merits, but when you ac

by flukus 8y ago

> On a separate(?) topic, a lot of tech organizations seem to be fond of saying they want to hear all ideas and judge the ideas on their merits, but when you actually say something that goes against popular opinion or conventional thinking within the organization, people aren't open to it or are even hostile or dismissive Another one I often hear is some variation of "present solutions not problems", often from developers and not just management. Except problems are easy to spot and solutions often require a substantial time investment to solve and present, time that won't be allocated unless problems are identified. Even if you spend your own time on the solution it will often be dismissed by people that don't see the problem in the first place, it's just "how we've always done it". It's basically a long winded way of telling people to stop complaining.

humanrebar 8y ago
> ...present solutions not problems... My favorite response to that is that understanding a problem is the first part of a solution. We had names for the sound barrier, smallpox, and moon landing problems long before we had solutions. Also, don't hire problem solvers and then complain that they are good at spotting problems.
JohnBooty 8y ago
> Another one I often hear is some variation of "present solutions > not problems", often from developers and not just management. > Except problems are easy to spot and solutions often require a > substantial time investment to solve and present, time that won't > be allocated unless problems are identified. This is one of the most powerful insights imaginable. From an employee's perspective, it's crucial to adopt the mentality of always striving to deliver solutions and not problems. Considered in a vacuum, yes, it's a valuable trait! Of course solutions are better than mere gripes! But it's equally crucial to realize that the common refrain of "bring me solutions, not problems" is -- as you say -- often a profound way for management to (perhaps sometimes unintentionally) bully, stifle, and ignore engineers. It works as an instrument of management's bullying because it preys upon the guilt we engineers feel when we present a problem without a solution. I should have been better. I should have developed a solution as well. That's what we tell ourselves. But, as you say, this is not always feasible. A solution may take days, weeks, months, or years. And the importance of the problem is often positively correlated with the time and resources needed to develop the solution.

by flukus 8y ago

humanrebar 8y ago

> ...present solutions not problems... My favorite response to that is that understanding a problem is the first part of a solution. We had names for the sound barrier, smallpox, and moon landing problems long before we had solutions. Also, don't hire problem solvers and then complain that they are good at spotting problems.

JohnBooty 8y ago

> Another one I often hear is some variation of "present solutions > not problems", often from developers and not just management. > Except problems are easy to spot and solutions often require a > substantial time investment to solve and present, time that won't > be allocated unless problems are identified. This is one of the most powerful insights imaginable. From an employee's perspective, it's crucial to adopt the mentality of always striving to deliver solutions and not problems. Considered in a vacuum, yes, it's a valuable trait! Of course solutions are better than mere gripes! But it's equally crucial to realize that the common refrain of "bring me solutions, not problems" is -- as you say -- often a profound way for management to (perhaps sometimes unintentionally) bully, stifle, and ignore engineers. It works as an instrument of management's bullying because it preys upon the guilt we engineers feel when we present a problem without a solution. I should have been better. I should have developed a solution as well. That's what we tell ourselves. But, as you say, this is not always feasible. A solution may take days, weeks, months, or years. And the importance of the problem is often positively correlated with the time and resources needed to develop the solution.