@StarkRG @jonm I remember learning the following rules back in 2005 or even earlier:
- Praise specifically and criticise generally
- Double all time estimates made by your developers and take them to the next unit (e.g. 2 days become 4 weeks) before passing them on
- Agree on a clear vocabulary, write it down and stick to it
The last point especially helps with quickly seeing which employees either lack the necessary precision/focus or tend to make things overly complicated
And yet, look at how many 2-year projects never get finished after half a decade or more.
Always double the time estimate, then double again. Helps to get rid of the non-essential "nice to haves" that people keep trying to add "because it won't take that much longer" .
Because EVERYONE keeps trying to bargain down how long something should take, even though THEY CAN NOT DO IT THEMSELVES.
Trying to meet unreasonable deadlines, even if you succeed, just adds technical debt. Glad I'm retired, because if there's one thing I've learned, it's that management can't even manage themselves effectively. That's why they went into management. Because only those who can do, do. Those who can't go into management.
@barbra @StarkRG Technical debt is one of the things that drove me out of the industry. When combined with the unwillingness to walk away from sunk costs, the vast majority of my budgets maintained the status quo. This resulted in a lack of progress. When AI arrived I was tasked with creating a shadow data infrastructure to serve the machine. Shadow because I still needed validated systems to actually generate and maintain the data.
I was happily given the severence I requested as I had become insufferable about this topic.