My son is 11,autistic, and obsessed with Minecraft. I manage a team of 4 Database Engineers. At some point I started to talk to them like how the parenting courses told me to communicate with my son and the team morale and overall performance has shot up so much we got an award
@fesshole Would you mind sharing some examples? This is great!
@jonm Very broadly (so not examples at all), communicate conscientiously and unambiguously (try to use words that don't have double meanings unless you're trying to be playful), realise that misunderstandings will _still_ happen and plan accordingly (if it's important, double check before they spend a whole day doing the wrong thing). Keep criticisms to a minimum and general while piling on praise for specific accomplishments (not just participation-trophy praise).
(1/2)
@jonm Most of all, give people the time to complete their tasks in the way that best works for them. Deadlines are an unfortunate fact of life, but don't create unnecessary deadlines that just stress people out, and try to plan for both people to be slower and more meticulous and for unforseen delays. You don't need to go all Scotty and quadruple any time estimate, but at least increase it by half if not doubling it.
(2/2)
@StarkRG @jonm This is all standard management advice, TBH, but too many people in management positions don't follow it.

@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

@Sturmflut @jonm Increasing days to weeks seems like the kind of thing you'd teach if you don't want to teach how to properly estimate project timelines (or if the person in question is severely time-blind, but it's probably better to just not rely on them to make such estimates in the first place). You need buffer, but telling a client or your boss that a project that you've estimated to take five months is actually going to take a decade is ridiculous. Or a two-year project becomes 4 decades?

@StarkRG

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.