In one of his essays, Paul Graham remarks that the startups at Ycombinator who fail have several traits in common, and one of those traits is that they don't listen. He meant they don't listen to him, but I would make it general -- these failed leaders often don't listen to their own teams.
I've been surprised at how often I have an important insight about a business, and my clients/managers feel uncomfortable with my insight. The most common reaction I get is "We need to stay focused on ideas that deliver real business value." But I can think of examples where that response couldn't possibly be an honest response, since the top leadership felt the company was in crisis, and they were trying to brainstorm new ideas for moving forward.
I was present for cases where software developers push for a new way of doing things, and the top management pushes for the status quo -- and this happens even when the top leadership feels the company is in crisis and the status quo is untenable.
The most rational explanation for this behavior is that the top leadership is worried that a new idea will take too much time, or cost too much money. The tech team might say "We have this brilliant idea, and it will take 3 months to implement" but the top leadership is worried that it will really take 6 months to implement. But this is really the same as saying that the company doesn't have the right leadership. If the status quo is untenable and the leadership lack the skills to properly evaluate alternative strategies, then new leadership is needed. But it is obviously difficult to get the top management to agree to this. I say "obviously" though in some sense it is surprising how many leaders would rather cling to power, and oversee a spectacular failure, than step aside and let someone else save the situation.
Why does top leadership drive the software developers so hard? There are several reasons. Fear of failure. Fear of unknown risks. Fear of uncontrolled costs. Fear of unexpected expenses. Fear of having to rely on something that one doesn't understand. Demanding long hours, and implementing rituals such as Agile or Scrum, are seen as ways of reducing risk. And then of course, there is the simple fact that the top leadership can do this -- the USA has weak labor unions, the tech industry has almost no labor unions, therefore the government allows harsher working conditions than what you find in France or Germany or Sweden.
This sounds like a very one-sided perspective. Because while we devs might not want to admit it, incremental improvements in product quality don't have a huge business impact. There are 3 states of a product -- Not Working, Works OK, and AMAZING. Not working --> Works OK is the initial dev of a product, so you are likely already past that. Now, if your improvements don't move the product from OK to Amazing, or if your product is already amazing, but the business has other problems... then your organization is at a point where devs simply don't have the business impact that a refactoring of sales/marketing/strategy can have. This is not a bad thing -- it means the devs did their job, and everyone else needs to step up.
But unless you understand the bigger picture of the business, it can seem like they are ignoring you. The truth is, they aren't rejecting your idea... they just think it isn't making the leap to amazing.
I'm not sure who are responding to, but you are not responding to me. If you re-read what I wrote, you'll see that I was speaking of cases where the leadership agreed that the status quo had failed.
I've been surprised at how often I have an important insight about a business, and my clients/managers feel uncomfortable with my insight. The most common reaction I get is "We need to stay focused on ideas that deliver real business value." But I can think of examples where that response couldn't possibly be an honest response, since the top leadership felt the company was in crisis, and they were trying to brainstorm new ideas for moving forward.
I was present for cases where software developers push for a new way of doing things, and the top management pushes for the status quo -- and this happens even when the top leadership feels the company is in crisis and the status quo is untenable.
The most rational explanation for this behavior is that the top leadership is worried that a new idea will take too much time, or cost too much money. The tech team might say "We have this brilliant idea, and it will take 3 months to implement" but the top leadership is worried that it will really take 6 months to implement. But this is really the same as saying that the company doesn't have the right leadership. If the status quo is untenable and the leadership lack the skills to properly evaluate alternative strategies, then new leadership is needed. But it is obviously difficult to get the top management to agree to this. I say "obviously" though in some sense it is surprising how many leaders would rather cling to power, and oversee a spectacular failure, than step aside and let someone else save the situation.
Why does top leadership drive the software developers so hard? There are several reasons. Fear of failure. Fear of unknown risks. Fear of uncontrolled costs. Fear of unexpected expenses. Fear of having to rely on something that one doesn't understand. Demanding long hours, and implementing rituals such as Agile or Scrum, are seen as ways of reducing risk. And then of course, there is the simple fact that the top leadership can do this -- the USA has weak labor unions, the tech industry has almost no labor unions, therefore the government allows harsher working conditions than what you find in France or Germany or Sweden.