| One trick, if you can get away with it, is to ensure that you are always estimating for a fixed scope exclusive of unknown unknowns. You should not provide an estimate for "feature X implemented", but rather for "feature X engine". If you discover additional work to be done, then you need to add "existing code refactor", "feature X+Y integration", etc. as discovered milestones. Unfortunately, you need that nomenclature and understanding to go up the chain for this to work. If someone turns your "feature X engine" milestone into "feature X complete" with the same estimate, you are screwed. ------ There is a related problem that I've seen in my career: leadership thinks that deadlines are "motivating". These are the same people that want to heat their home to a temperature of 72F, but set the thermostat to 80F "so it will do it faster". I was once in a leadership meeting, where the other participants forgot that I, lowly engineer, was invited to this meeting. Someone asked if we should accept that deadline X was very unlikely to be met, and substitute a more realistic deadline. To which the senior PM responded that "we never move deadlines! Engineering will just take any time given to them!" Engineering, in that case, gave the time back when I left that team. |
| Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device. Also, many engineering teams WILL take any time given to them. But instead of making estimates and plans into hard deadlines (when facing the engineers), managers can make sure the organization is ready for overruns. And as the estimated completion time approaches, they can remain reasonable understanding as long as the devs can explain what parts took longer than estimated, and why. Part of this is for the manager to make sure customers, sales and/or higher level managers also do not treat the planned completion time as a deadline. And if promises have to be made, customer facing deadlines must be significantly later than the estimated completion time. |
| |
| ▲ | avidiax 6 days ago | parent | next [-] | | > Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device. The thermostat is meant to be far away. This isn't a valid analogy if the thermostat is measuring the temperature of the heater rather than the room. > Also, many engineering teams WILL take any time given to them. Agree, engineering teams are not single-stage heaters. They can make more progress toward the goal by working harder (in the short term), or reducing quality, or reducing scope. But holding hours/week, quality and scope equal, engineering teams aren't going to implement faster because the deadline is sooner. If there is actual slack in the schedule, they will tend to increase scope (i.e. address tech debt, quality of life improvements, plan better). It might seem that engineers take all the time given to them because most engineering orgs tend to oversubscribe engineering (which makes business sense, since engineering is expensive). | | |
| ▲ | trashtester 4 days ago | parent [-] | | > If there is actual slack in the schedule, they will tend to increase scope (i.e. address tech debt, quality of life improvements, plan better). If all your engineers will make use of most of the slack for such purposes, rather than unproductive activities, you've either been very skillful or very lucky in hiring them (or at least their team leads, etc). A lot of engineers (myself included) will produce more if there is at least a moderate amount of pressure applied towards delivering something useful relatively soon. Too much pressure can definitely have the reverse effect, as it introduces more long term technical debt than what is saved in the short term. Also, intermittent period of low pressure can lead to innovation that wouldn't happen if the pressure is always constant. Still, most tech teams I've worked with will tend to become a bit too relaxed (leading to shorter days, longer breaks, more chatter/social media, etc) if they are presented with delivery dates 1 year in the future for tasks that "feel" like it's only going to take 3-6 months. Which may very well lead to the task taking 15-18 months instead of the 10-12 months it really takes due to those unexpected complications nobody explicitly thought about. This also transfers to "agile" development, and in many cases "agile" can make these issues even worse, especially for deliverables that require months to years of effort before anything economically self-sustained can be released. (For instance, if you need to replace a legacy system, the new system isn't delivering net benefit until the legacy system can be shut down.) |
| |
| ▲ | nikau 3 days ago | parent | prev [-] | | > Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device. What logic is that based on? Most devices are just bang bang controlled on or off - so setting to 80 or 72 makes no difference. Some rare invertor devices may use PID to ramp down as they approach the setpoint, but that's not common. | | |
| ▲ | trashtester 3 days ago | parent [-] | | I'm going to assume we're talking about an oven below, but the principle also applies to AC: A thermostat attached to a device will measure the temperature near the device, which typically is a bit higher elsewhere in the room, even if the sensor is at the air intake. Also, even when the air temperature in a room reaches 72F, the walls may still be cold. This means that the temperature experienced by a person in the room will be lower than 72F, since the person will be exposed to less infrared radiation than if the room had been at 72F for a longer period of time. So, if the goal is to reach a stable 72F (as felt by a human), the fastest way is to turn it to maybe 80F, and then turn it down when the temperature feels about right, or even a bit later (due to the thermal mass in the walls, furniture, etc). If instead, the the temperature is set to 72F from the start, the oven will start to switch on and off quite freqently as air near the sensor reaches ~72F, and the felt temperature in the room will approach 72F assymptotically. I live in an old house in a place that can get very cold, and I know this first hand. | | |
| ▲ | nikau 3 days ago | parent [-] | | For a large room where the vent is far away from the sensor I can get behind that. For a fan forced oven, not so much. |
|
|
|
