Ways to annoy your senior engineer

> If you’re emotionally upset when you’re helping people they’re going to feel that and not want to try their best.

I'm here to solve problems, not being emotion consult.

When techniques are misused they are misused.

The fact that there are bad project managers that don't know how to use a schedule are just as bad as the crappy "scrum masters" and "product managers" that don't know what "agile" actually means.

A good project manager will be continuously revising their schedule, based on updated estimates on the tasks. They will know how to compare it to, and update, the baseline.

Not sure what you mean specifically by "bus number" but happy to learn.

The GANTT chart is just a format of displaying tasks, their resources and dependencies. The actual DAG is a pure data structure.

If you put a confidence level indication on the estimates, a good project management tool will also be able to do analysis of the critical path (ie the length in time of the longest path) with a level of confidence on earliest/latest predicted end dates.

People think that nonsense like "t-shirt sizing" actually means anything other than "wild-assed guess" or that burndown charts are useful when adjusting future estimates.

All techniques to avoid doing the hard work of scheduling and project management.

> They do, and if they get disrupted by competition, this way of working is not the biggest reason for it.

I interviewed with a company that was "disrupted" precisely because of this way of working. (They have a well-known interrupt-driven culture.) They were a major vendor, and were trying to move their business into the area that finally disrupted them. (They were a major choice in software projects in the late 1990s and early 2000s, then lost business due to competition, and then changes in the 2010s really ate into their market.)

I took the interview for "career development," and generally planned to decline the job unless it was huge bucks. During the interview, when I asked the manager about interruptions, it became clear that they were the kind of place that the article described, and that's why their initiative is an "also ran."

Anyway, in the area they were trying to move their business to, no one generally considers them a major player. Their three major competitors are mentioned all the time, but their name rarely comes up.

I consider them disrupted at this point: Both in their product that had success in the 1990s and 2000s, and in their ability to adapt to market conditions established in the 2010s and firmly expected today. They could move into today's market if they had a better way of working, though.

I actually have. I'm completly remodeling a rental property after a nightmare tenant. I'm totally familiar with what you're talking about and am not disagreeing, but my point was more that they still give you an estimate. I've never had a contractor or someone he's hired not provide an estimate.

I know their number is going to be off, so personally, I mentally double any number they tell me, but having that starting point is important. If they tell me it's going to be $6k for a new kitchen, I can budget $12k. If they just went ¯\_(ツ)_/¯ then I don't even have a starting point which is way less helpful.

> "What’s your estimate? No, that won’t work"

That's a different problem though. The issue isn't that estimating the project is useless, it's that you work with people who don't respect the estimate and think it's a negotiation.

I get that you're saying that in that situation the only winning move it to not play, but that issue you're identifying isn't actually an issue with the estimate itself.

> If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time

I get what you're saying and it's a valid suggestion, but personally, I find it better to work the other way. Engineer estimates a best case scenario with all the bells and whistles and then it becomes a discussion with stakeholders as to what can be cut to fit the timeline.

The reason I think that is better is because most of the time features that an engineer priorities may not align with what stakeholders priorities or there maybe tradeoffs a stakeholder is willing to make once they see estimates. For example A stakeholder may say, I really want it to do X, so the engineer comes back and says X will take 2 months to build and that's that, but if the stakeholder has the full project estimate in front of them, they might go, I really wanted X, but it looks like we can do A, B, and C in the same amount of time as X and those three things combined would be more impactful than X, so let's do that instead.

Again, you're suggestion is totally valid and I'm sure many people do it that way, but I've gotten better results the other way.