5 ms·

This is one of those wishful thinking rants that serves to highlight the rose-colored glasses many developers see the business world through. All good things ev

This is one of those wishful thinking rants that serves to highlight the rose-colored glasses many developers see the business world through. All good things eventually come to an end, and you need to be ready for the inevitable. The author described two perfectly good responses for this scenario, and managed to paint them both as the cowards path. Leaving the company, and checking out mentally, letting the people with the responsibility hang themselves with their own rope. The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work. I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities. There's always good, solid ground to retreat to in case you get routed. Complaints like this remind me of a rich wanker bitching about the valet not putting his seat back the way he left it. Just adjust it yourself and move on with life. Life's too short to get mad about stuff like that.

fsloth 11y ago
The author is simply describing a transformation from a system driven mostly by intrinsic motivation to a system driven by an extrinsic one. Typically complex tasks are solved better in an environment with emphasis on intrinsic motivators. It's not wissful thinking. It's a keen observation. Basically management offloads the responsibility of actually managing to a process of accounting. It's a less skillfull, less productive, but a much more predictable form of management. The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.
- skewart 11y ago
  This, 100%. I agree that complex tasks are generally better solved in an environment driven by intrinsic motivation - heck, probably all tasks and not just complex tasks. I'm not sure if Jira and other task tracking tools can be used just as well to document work done by intrinsic motivators though. I mean, yes, they _can_ be, but I don't think they're as good as they could be. In fact, I'd say there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made while also not getting in the way of the ad hoc workflows the post describes.
  - fsloth 11y ago
    "there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made" That's not a tool gap but a trust gap in the team, and no tool can remedy that, IMO.
  - marcosdumay 11y ago
    The same research that shows that complex tasks are better solved with intrinsic motivation also shows that simple tasks are better solved with extrinsic motivation. That is, measuring mechanical/repetitive work does increase its productivity. What we have today is an almost complete lack of mechanical/repetitive work to measure.
  - amag 11y ago
    I've found that tracking tools are good to have even at times when I've been able to work in the manner of freedom the article describes. It's just that they are used differently, more in a way to help remember things. Things that either needs to be done or things that have been done. Especially those nightmarish things that took a long time to solve, so documenting the process is good for the future, in case it happens again. It wasn't always like that for me (document, bah! comments, bah!) but as I grow older I've come to appreciate the possibility to offload information in my brain to a more persistent media. This way I only keep the index in my brain ("Hey, wait a minute, I recognize this..."). Maybe I'm just lazy but I hate doing the same thing twice. I also hate saying the same thing twice so before I explain something to someone I like to write it down and give them a copy. Then when they ask me about it I simply refer them to the document (in a friendly (RTFM) manner).
- mannykannot 11y ago
  > The problem was not the Jira. The first problem was thinking that you could set meaningful hard deadlines for inadequately defined goals. The second problem was acting as though they were meaningful.
gearoidoc 11y ago
"I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about." wat
- 746F7475 11y ago
  >magic
- Lawtonfogle 11y ago
  Sounds like a 'you have a better than average income so you shouldn't complain about stuff'. Two problems: 1. Fiscal income is not the end all be all of determining quality of life. 2. The argument itself doesn't work; one only needs to apply it to others to see how it works. Take a poor person on welfare and tell them they don't have to worry about things that people in third world countries where welfare doesn't exist do. The whole 'how are they poor if they have refrigerators' argument. You quickly see how empty the argument is.
hartator 11y ago
You seem to forget that most of the best coders have spent countless hours learning a ton of things. It's not something easy or without a tax on the mental.
- vinceguidry 11y ago
  I found it easy enough. I learn new things for fun. I don't consider it taxing at all. Anyone who wants to pay me to learn something new, I'm happy to oblige them.
  - johnsonjo 11y ago
    > I found it easy enough. I learn new things for fun. I don't consider it taxing at all I have no doubts that you find learning fun and find it easy, but the last sentence I'm a little hesitant with. It reminds me of a single pane comic strip I recently saw. It was of a business man receiving a logo from a designer, and he said, "Why should I pay you $X dollars for a logo you designed in ten minutes?". To which the artist replied, "It took me ten years to get that quick at making logos." Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out. I would like to stress that programming is very hard and taxing when you are completely new to it and it progressively gets easier and easier. I only was recently re-informed of how hard programming is as I have recently helped my brother begin programming, because like you for the most part I find it relatively simple to learn something new. Though I find it easy to learn I notice when I first dive into a new framework, language, or codebase I do have to watch my stress levels and make sure I'm not getting overwhelmed by it. >I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities. If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem. Though some might oppose it I think the idea of educating more people in CS in grade schools might help combat that. To the second sentence, I would say everyone has their own measurement of what a necessity and a nice-to-have is, but often most things people complain about aren't completely necessary. You can tell he (the blog poster) has a problem with the way things are being done at his company I appreciated his opinion although I don't necessarily take his stance.
bsandert 11y ago
> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. You sound just like a church. Friction is good, differences in opinions and priorities are good. Especially in a creative environment. When a part of that is silenced based on just organisational/hierarchical arguments, everyone involved will become less effective in one way or another. I do agree with you that after not being able to fix the organisational problem, walking away is not the cowards path.
- vinceguidry 11y ago
  As an individual contributor, your ability to fix organizational problems is limited and efforts to do so are almost inevitably plagued by wishful thinking. You're just not in a position to be able to change how people think about things. Your skillset is not with people, it's with code.
  - soft_dev_person 11y ago
    And here I thought I was cynical...
  - skewart 11y ago
    That really depends on the IC and the organization. That's probably true at some places. At a 30 person startup you'd be amazed at how much individual engineers can change things.
- rglullis 11y ago
  > Especially in a creative environment. It is not a creative environment. We are talking about mid- to big-sized projects and companies here. Not the scrappy startup, not the open source consultant shop, not the small niche application for your Macbook. Differences in opinions are good, provided the team as a whole is reasonably aligned. Too much divergence and this "room for creativity" becomes a schizophrenic organization.
  - TheOtherHobbes 11y ago
partycoder 11y ago
What the author describes is that the manager manipulated the consensus building in the team, by adding friends to the team so he can start ignoring them. Consensus building is a key part of any organization and doing this is not ethical. Then, what you describe: reducing technical debt is a nice to have? life is too short to care about quality? That's pretty much, in your own words "the coward way": "checking out mentally".
- vinceguidry 11y ago
  This is almost completely wrong. Building consensus is just one management style. It is by no means the only one, or even the only effective one. It's not unethical to manage in a different fashion. The people being managed don't like it, but that doesn't make it unethical. Just find a better job. Checking out and doing what you're told is a rational response, one that management would not be opposed to seeing. You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain? Being able to come into work, do a job, and go home without having to be worried about the outcome of your efforts, to have someone else on the hook for it, that would be looked at by a lot of people as a luxury. But devs all seem to have this ego that keeps them from being able to appreciate the reprieve. Yes. Check out mentally. Do your job and go home at 5 and do all those other things in your life that you've been neglecting because you were putting that energy into your job. Spend time with your wife and kids, date if you're single. Work on your hobbies. Enjoy it because that's not going to last forever either.
  - marcosdumay 11y ago
    You are assuming that staying 8 hours a day in a job you don't care about is less consuming than staying those 8 hours in a job you love. I can't even imagine where did you get that from. One will cause deep depression and burnout in no time - the other is a wonderful life experience.
    - deleted 11y ago
      [deleted]
Ace17 11y ago
The success/failure of a project hinges on lots of things. Amongst them, code quality, which heavily dictates your reactivity. Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests". Another thing: high-tech is an innovation-driven market. Most of the ideas are going to come from your developers, so why adopt a management style killing their creativity?
- bb88 11y ago
  > Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests". That's the entire idea of technical debt. It's just like real debt, only that it's cost is development time. And it takes time to pay it down. The only difference is that it's not reported on a balance sheet, so management doesn't care about it.
  - vinceguidry 11y ago
    It's their codebase, they paid for it. If they don't want to maintain it properly, then it's on them. It will just get more and more expensive to maintain until they replace it with newer technology. Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly. Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right. If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.
    - humanrebar 11y ago
      > It's their codebase, they paid for it. > Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. You can't have it both ways. Either the employer owns the code and is responsible for monitoring and managing technical debt, or it's the dev's responsibility and the employer needs to make that clear and hire people who can balance decisions effectively.
skewart 11y ago
> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work. I don't want to put too fine of a point on it, but it sounds like you might have missed the point of the article. The author was saying that efforts to improve business outcomes by closely managing engineering work often have the exact opposite effect of what is intended. As you soon as you start trying to measure developers you slow them down, hence the title. I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down." The author does seem to think he knows better than anxious middle managers who are overly eager to change how things are done. But, well, I'm inclined to believe that he does. That said, there are very real concerns and worthwhile motivations that lead managers to start closely project managing engineering. And in reality free-form engineering can lead to lots of time wasted on personal obsessions, or just plain slacking. So I agree about the rose-colored glasses.
- vinceguidry 11y ago
  > I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down." No, it's not. What is is when they say no and you persist in your belief. They said no for a reason, not grasping that reason or willfully ignoring it is a function of ego.
cousin_it 11y ago
I'm 100% in favor of "checking out mentally". Only I describe it differently. When you start insisting on what's good for the business and your employer disagrees, there's only so far you should go, because in the end they're paying you to do what they (possibly unreasonably) want. It's okay to push back against micromanagement, but that should be viewed as a selfish struggle for better work conditions (or better pay to compensate), not a selfless struggle to make the company better.
JanneVee 11y ago
Sure rose-colored glasses is a part of it. But at the same time, you have them too. The problem here is lack of leadership and the organization is trying to solve it with management. The parable of the loggers is apt in the authors situation. > A group of loggers is busy chopping away doing great work under the supervision of the managers and achieving high productivity and throughput. Someone from a mountain overlooking the forests notices something and shouts "hey, you down there ..." - reply: "we are busy, and making great progress" ... and the person on the mountain yells "Wrong forest!" I would try to leave the company, checking out mentally while waiting for the right opportunity and getting behind management helping them get the rope so they can hang themselves. Because ultimetly the company is bigger than me and if I'm not happy working there just building features why would I stay? I don't want a reputation of building buggy software, because the company I work for doesn't focus on it. The company has no loyalty to me if times are tough, because thay lay me off if times are tough. So companies shouldn't expect any loyalty to stay from me either if they take decision that are against my interests.
- vinceguidry 11y ago
  > The problem here is lack of leadership and the organization is trying to solve it with management. Management is a resource that can be easily added or subtracted from an organization, leadership is not. Good leaders are rare, but management can be taught.
  - JanneVee 11y ago
    Yeah and management alone doesn't suffice. Only managing the adding features and not managing the quality is a problem, and as I see it lack of leadership.
    - vinceguidry 11y ago
      You didn't seem to grasp my point. Management is a resource a company can throw at a problem. Leadership is not. Positing solutions that can't be implemented is the very definition of wishful thinking. Calling it a lack of leadership isn't helpful. You need to break the problem down further and try to find a way to solve it that doesn't involve supermen.

fsloth 11y ago

The author is simply describing a transformation from a system driven mostly by intrinsic motivation to a system driven by an extrinsic one. Typically complex tasks are solved better in an environment with emphasis on intrinsic motivators. It's not wissful thinking. It's a keen observation. Basically management offloads the responsibility of actually managing to a process of accounting. It's a less skillfull, less productive, but a much more predictable form of management. The problem was not the Jira. It was the new PM who instituted the cultural change. Jira can be used just a well to document work done by intrinsic motivators.

skewart 11y ago
This, 100%. I agree that complex tasks are generally better solved in an environment driven by intrinsic motivation - heck, probably all tasks and not just complex tasks. I'm not sure if Jira and other task tracking tools can be used just as well to document work done by intrinsic motivators though. I mean, yes, they _can_ be, but I don't think they're as good as they could be. In fact, I'd say there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made while also not getting in the way of the ad hoc workflows the post describes.
- fsloth 11y ago
  "there's a big gap in the market for a solution that gives non-technical managers some reassurance that progress is being made" That's not a tool gap but a trust gap in the team, and no tool can remedy that, IMO.
- marcosdumay 11y ago
  The same research that shows that complex tasks are better solved with intrinsic motivation also shows that simple tasks are better solved with extrinsic motivation. That is, measuring mechanical/repetitive work does increase its productivity. What we have today is an almost complete lack of mechanical/repetitive work to measure.
- amag 11y ago
  I've found that tracking tools are good to have even at times when I've been able to work in the manner of freedom the article describes. It's just that they are used differently, more in a way to help remember things. Things that either needs to be done or things that have been done. Especially those nightmarish things that took a long time to solve, so documenting the process is good for the future, in case it happens again. It wasn't always like that for me (document, bah! comments, bah!) but as I grow older I've come to appreciate the possibility to offload information in my brain to a more persistent media. This way I only keep the index in my brain ("Hey, wait a minute, I recognize this..."). Maybe I'm just lazy but I hate doing the same thing twice. I also hate saying the same thing twice so before I explain something to someone I like to write it down and give them a copy. Then when they ask me about it I simply refer them to the document (in a friendly (RTFM) manner).
mannykannot 11y ago
> The problem was not the Jira. The first problem was thinking that you could set meaningful hard deadlines for inadequately defined goals. The second problem was acting as though they were meaningful.

gearoidoc 11y ago

"I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about." wat

746F7475 11y ago
>magic
Lawtonfogle 11y ago
Sounds like a 'you have a better than average income so you shouldn't complain about stuff'. Two problems: 1. Fiscal income is not the end all be all of determining quality of life. 2. The argument itself doesn't work; one only needs to apply it to others to see how it works. Take a poor person on welfare and tell them they don't have to worry about things that people in third world countries where welfare doesn't exist do. The whole 'how are they poor if they have refrigerators' argument. You quickly see how empty the argument is.

hartator 11y ago

You seem to forget that most of the best coders have spent countless hours learning a ton of things. It's not something easy or without a tax on the mental.

vinceguidry 11y ago
I found it easy enough. I learn new things for fun. I don't consider it taxing at all. Anyone who wants to pay me to learn something new, I'm happy to oblige them.
- johnsonjo 11y ago
  > I found it easy enough. I learn new things for fun. I don't consider it taxing at all I have no doubts that you find learning fun and find it easy, but the last sentence I'm a little hesitant with. It reminds me of a single pane comic strip I recently saw. It was of a business man receiving a logo from a designer, and he said, "Why should I pay you $X dollars for a logo you designed in ten minutes?". To which the artist replied, "It took me ten years to get that quick at making logos." Learning the art of software development is similar, you need to get a solid foundation in your domain of knowledge before you can build anything both well and quickly or before you start to find things easier to figure out. I would like to stress that programming is very hard and taxing when you are completely new to it and it progressively gets easier and easier. I only was recently re-informed of how hard programming is as I have recently helped my brother begin programming, because like you for the most part I find it relatively simple to learn something new. Though I find it easy to learn I notice when I first dive into a new framework, language, or codebase I do have to watch my stress levels and make sure I'm not getting overwhelmed by it. >I mean, come on, in the grand scheme of things, developers are wizards who never have to be worried about 90% of the things other people in the world have to worry about. These finer qualities of career enjoyment are nice-to-haves, not necessities. If by wizards you mean everything they do seems like magic to everyone who has never written any code and themselves and their methods are often misunderstood I would say that is true, and I think that may be part of the problem. Though some might oppose it I think the idea of educating more people in CS in grade schools might help combat that. To the second sentence, I would say everyone has their own measurement of what a necessity and a nice-to-have is, but often most things people complain about aren't completely necessary. You can tell he (the blog poster) has a problem with the way things are being done at his company I appreciated his opinion although I don't necessarily take his stance.

bsandert 11y ago

> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. You sound just like a church. Friction is good, differences in opinions and priorities are good. Especially in a creative environment. When a part of that is silenced based on just organisational/hierarchical arguments, everyone involved will become less effective in one way or another. I do agree with you that after not being able to fix the organisational problem, walking away is not the cowards path.

vinceguidry 11y ago
As an individual contributor, your ability to fix organizational problems is limited and efforts to do so are almost inevitably plagued by wishful thinking. You're just not in a position to be able to change how people think about things. Your skillset is not with people, it's with code.
- soft_dev_person 11y ago
  And here I thought I was cynical...
- skewart 11y ago
  That really depends on the IC and the organization. That's probably true at some places. At a 30 person startup you'd be amazed at how much individual engineers can change things.
rglullis 11y ago
> Especially in a creative environment. It is not a creative environment. We are talking about mid- to big-sized projects and companies here. Not the scrappy startup, not the open source consultant shop, not the small niche application for your Macbook. Differences in opinions are good, provided the team as a whole is reasonably aligned. Too much divergence and this "room for creativity" becomes a schizophrenic organization.
- TheOtherHobbes 11y ago

partycoder 11y ago

What the author describes is that the manager manipulated the consensus building in the team, by adding friends to the team so he can start ignoring them. Consensus building is a key part of any organization and doing this is not ethical. Then, what you describe: reducing technical debt is a nice to have? life is too short to care about quality? That's pretty much, in your own words "the coward way": "checking out mentally".

vinceguidry 11y ago
This is almost completely wrong. Building consensus is just one management style. It is by no means the only one, or even the only effective one. It's not unethical to manage in a different fashion. The people being managed don't like it, but that doesn't make it unethical. Just find a better job. Checking out and doing what you're told is a rational response, one that management would not be opposed to seeing. You're still getting paid the same, but are having your responsibilities taken away. Most other people are overworked and underpaid, you're getting underworked and overpaid. So why complain? Being able to come into work, do a job, and go home without having to be worried about the outcome of your efforts, to have someone else on the hook for it, that would be looked at by a lot of people as a luxury. But devs all seem to have this ego that keeps them from being able to appreciate the reprieve. Yes. Check out mentally. Do your job and go home at 5 and do all those other things in your life that you've been neglecting because you were putting that energy into your job. Spend time with your wife and kids, date if you're single. Work on your hobbies. Enjoy it because that's not going to last forever either.
- marcosdumay 11y ago
  You are assuming that staying 8 hours a day in a job you don't care about is less consuming than staying those 8 hours in a job you love. I can't even imagine where did you get that from. One will cause deep depression and burnout in no time - the other is a wonderful life experience.
  - deleted 11y ago
    [deleted]

Ace17 11y ago

The success/failure of a project hinges on lots of things. Amongst them, code quality, which heavily dictates your reactivity. Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests". Another thing: high-tech is an innovation-driven market. Most of the ideas are going to come from your developers, so why adopt a management style killing their creativity?

bb88 11y ago
> Having a technically-blind management isn't going to work, especially if it leads to policies like "no refactoring" or "no time for tests". That's the entire idea of technical debt. It's just like real debt, only that it's cost is development time. And it takes time to pay it down. The only difference is that it's not reported on a balance sheet, so management doesn't care about it.
- vinceguidry 11y ago
  It's their codebase, they paid for it. If they don't want to maintain it properly, then it's on them. It will just get more and more expensive to maintain until they replace it with newer technology. Developers fetishize their codebases and complain about unpaid technical debt, but not all the bad code I've run across I can push off to management making the wrong decisions. I've seen a lot of bad decisions made by the original developer too, who just did things improperly. Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. If you're incurring technical debt, then you need to spend some time analyzing it and coming to a real understanding of the tradeoffs you're making in doing it a certain way. Hopefully you'll have documentation somewhere that describes the debt, what's being worked around, and what it would take to do it right. If you're not doing that, then you're just leaving a mess for the next guy. Messy work isn't technical debt, it's just sloppy work.
  - humanrebar 11y ago
    > It's their codebase, they paid for it. > Devs have this nasty tendency to push their mistakes onto their employer by calling it technical debt. You can't have it both ways. Either the employer owns the code and is responsible for monitoring and managing technical debt, or it's the dev's responsibility and the employer needs to make that clear and hire people who can balance decisions effectively.

skewart 11y ago

> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. It's cold comfort to be right, so just get behind management and try to make the new direction work. I don't want to put too fine of a point on it, but it sounds like you might have missed the point of the article. The author was saying that efforts to improve business outcomes by closely managing engineering work often have the exact opposite effect of what is intended. As you soon as you start trying to measure developers you slow them down, hence the title. I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down." The author does seem to think he knows better than anxious middle managers who are overly eager to change how things are done. But, well, I'm inclined to believe that he does. That said, there are very real concerns and worthwhile motivations that lead managers to start closely project managing engineering. And in reality free-form engineering can lead to lots of time wasted on personal obsessions, or just plain slacking. So I agree about the rose-colored glasses.

vinceguidry 11y ago
> I don't think it's "ego-belief that you know better" if a business says "we want to ship things faster, let's try doing X" and you see that X actually slows things down to then say, "hey let's not do X, it actually slows things down." No, it's not. What is is when they say no and you persist in your belief. They said no for a reason, not grasping that reason or willfully ignoring it is a function of ego.

cousin_it 11y ago

I'm 100% in favor of "checking out mentally". Only I describe it differently. When you start insisting on what's good for the business and your employer disagrees, there's only so far you should go, because in the end they're paying you to do what they (possibly unreasonably) want. It's okay to push back against micromanagement, but that should be viewed as a selfish struggle for better work conditions (or better pay to compensate), not a selfless struggle to make the company better.

JanneVee 11y ago

Sure rose-colored glasses is a part of it. But at the same time, you have them too. The problem here is lack of leadership and the organization is trying to solve it with management. The parable of the loggers is apt in the authors situation. > A group of loggers is busy chopping away doing great work under the supervision of the managers and achieving high productivity and throughput. Someone from a mountain overlooking the forests notices something and shouts "hey, you down there ..." - reply: "we are busy, and making great progress" ... and the person on the mountain yells "Wrong forest!" I would try to leave the company, checking out mentally while waiting for the right opportunity and getting behind management helping them get the rope so they can hang themselves. Because ultimetly the company is bigger than me and if I'm not happy working there just building features why would I stay? I don't want a reputation of building buggy software, because the company I work for doesn't focus on it. The company has no loyalty to me if times are tough, because thay lay me off if times are tough. So companies shouldn't expect any loyalty to stay from me either if they take decision that are against my interests.

vinceguidry 11y ago
> The problem here is lack of leadership and the organization is trying to solve it with management. Management is a resource that can be easily added or subtracted from an organization, leadership is not. Good leaders are rare, but management can be taught.
- JanneVee 11y ago
  Yeah and management alone doesn't suffice. Only managing the adding features and not managing the quality is a problem, and as I see it lack of leadership.
  - vinceguidry 11y ago
    You didn't seem to grasp my point. Management is a resource a company can throw at a problem. Leadership is not. Positing solutions that can't be implemented is the very definition of wishful thinking. Calling it a lack of leadership isn't helpful. You need to break the problem down further and try to find a way to solve it that doesn't involve supermen.