3 ms·

> You can’t pin down the when, how much, what and how all at the same time Precisely. And my point is that you should set the when and how much as soon as poss

by IMTDb 5y ago

> You can’t pin down the when, how much, what and how all at the same time Precisely. And my point is that you should set the when and how much as soon as possible. Then negotiate the what. Then, based on all these information, decide on the how. Usually tho, people love to start on the what, immediately think about the how, and give pointer on the how much. Inevitably, the when question comes, and can significantly alter the other points. Everyone hates to have their "perfect plan" questioned by an external deadline, and management is resented for it. As engineers, the how is where we have the most control and knowledge, so this should serve as an adjustment variable, not the other way around. The Milton quote applies really well to software engineering, we have all known tons of projects that linger in the "80% done" state for extended periods of time, it's a staple of engineering. A significant portion of project management is psychology. Some of the best PM I have had had almost 0 technical background.

doctor_eval 5y ago
I guess we really just differ in that I don't think the "when" is necessarily the most important thing. It's just as much a part of the negotiation as the what, how etc; it's just one dimension of many. It's often, but not always, the key driver. But you don't seem to be the kind of lazy manager that this article talks about. If you're OK to say that the date is the most important thing, and we understand that this might mean we have to sacrifice features or quality or whatever, then that's perfectly reasonable. It's an explicit trade off that you can communicate clearly to your team. But all too often, we're told that we need to have N features in T time, and when it's delivered half assed and full of bugs, well that's our fault. And I think that's the essence of lazy management, because it's really just trying achieve success through the force of will, which IME doesn't work very often.

by IMTDb 5y ago

doctor_eval 5y ago

I guess we really just differ in that I don't think the "when" is necessarily the most important thing. It's just as much a part of the negotiation as the what, how etc; it's just one dimension of many. It's often, but not always, the key driver. But you don't seem to be the kind of lazy manager that this article talks about. If you're OK to say that the date is the most important thing, and we understand that this might mean we have to sacrifice features or quality or whatever, then that's perfectly reasonable. It's an explicit trade off that you can communicate clearly to your team. But all too often, we're told that we need to have N features in T time, and when it's delivered half assed and full of bugs, well that's our fault. And I think that's the essence of lazy management, because it's really just trying achieve success through the force of will, which IME doesn't work very often.