3 ms·

> Ive also since college done the hard yards to learn to execute/lead and obtain multiple deep skills including coding. If you’re actually executing and delive

> Ive also since college done the hard yards to learn to execute/lead and obtain multiple deep skills including coding. If you’re actually executing and delivering results then you aren’t the stereotypical “idea guy” referred to here. The problem with the stereotypical “idea guy” is that their flurry of ideas and constant changes becomes a roadblock to delivering anything at all. Their team is constantly destroyed by direction changes and burned out from chasing moving targets before they can possibly hit those targets. The idea guy personality is the embodiment of the phrase “perfect is the enemy of good”. Every team has constrained resources, so delivering something imperfect is better than not delivering anything at all because the team burned out and ran out of money because the ideas were iterated faster than execution could allow.

planet-and-halo 6y ago
This is why economic thinking should be a part of every team's process. One of the major problems with technical projects is that many people can give an estimate of their value but only the developers can give an estimate of the cost—and they can usually only do that effectively after some iterations and starting to sketch out the problem. Usually organizations just ignore this problem and try to fix the cost upfront, which is where the whole "mythical man month / hours" phenomenon comes from. In a well-functioning Lean/Agile/whatever-you-want-to-call-it organization, there should be a constant ongoing evaluation of the work and its cost/benefit, and that should be updated as the devs learn more about the problem. When you do this, ideas are no longer "good" or "bad," they just have a value estimate and can be evaluated against other ideas. (And you can factor in things like switching costs when people throw out something totally new.)
- Dracophoenix 6y ago
  While I think that kind of thinking the kind that encourages bean counting and half-assery in the name of profit? I would certainly agree that having an ongoing basis for calculation is a metric. But when that metric becomes a target (and it will), you get disasters like the 737 MAX.
  - planet-and-halo 5y ago
    Bean counting is happening in your organization whether you like it or not, it's just a question of whether it's visible to you. I would much rather have it be an explicit part of the development process where the developers get some kind of input than have it hidden away and have edicts emerge from the ether to mess up their whole month. For a thoughtful view of this topic, I recommend "Principles of Product Development Flow."

planet-and-halo 6y ago

This is why economic thinking should be a part of every team's process. One of the major problems with technical projects is that many people can give an estimate of their value but only the developers can give an estimate of the cost—and they can usually only do that effectively after some iterations and starting to sketch out the problem. Usually organizations just ignore this problem and try to fix the cost upfront, which is where the whole "mythical man month / hours" phenomenon comes from. In a well-functioning Lean/Agile/whatever-you-want-to-call-it organization, there should be a constant ongoing evaluation of the work and its cost/benefit, and that should be updated as the devs learn more about the problem. When you do this, ideas are no longer "good" or "bad," they just have a value estimate and can be evaluated against other ideas. (And you can factor in things like switching costs when people throw out something totally new.)

Dracophoenix 6y ago
While I think that kind of thinking the kind that encourages bean counting and half-assery in the name of profit? I would certainly agree that having an ongoing basis for calculation is a metric. But when that metric becomes a target (and it will), you get disasters like the 737 MAX.
- planet-and-halo 5y ago
  Bean counting is happening in your organization whether you like it or not, it's just a question of whether it's visible to you. I would much rather have it be an explicit part of the development process where the developers get some kind of input than have it hidden away and have edicts emerge from the ether to mess up their whole month. For a thoughtful view of this topic, I recommend "Principles of Product Development Flow."