Fesshole 🧻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
Jon Moore
StarkRG@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)
(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)
(2/2)
Sturmflut@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?
barbraAnd 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 "look at how many 2-year projects never get finished"
That's usually not down to project planning or timeline estimation, though. It'll be down to poor management, funding issues, shifting priorities, and organisational restructuring.
That's usually not down to project planning or timeline estimation, though. It'll be down to poor management, funding issues, shifting priorities, and organisational restructuring.
Poor management, funding issues, shifting priorities, and organisational restructuring are ALL management failures. This has always been the case. Just look at the failure of the Denver baggage handling system, originally budgeted at under $200 million and time-compressed from 4 years to less than half, then delayed the opening of the airport by 16 months before being abandoned when it threatened the credit rating of the city of Denver.
Boeing had plenty of cost-plus contracts that didn't deliver anywhere :ear on time of budget, ditto Lockheed-Martin, the F35 is way slower than a 50-year-old F16. Not for lack of funding.
So double estimates, double again, and you MIGHT be safe. Both in time and budget.
@barbra Yeah, I don't understand how they're doing their timeline estimations. My guess is that someone competent draws up an estimation, trying to squeeze it as tight as they can while still keeping a teensy bit of buffer time, then they pass it up the chain where someone goes "oh, they always quadruple these estimates" so, when they present the bid to the client, they half the estimate and, oh look, they won the contract because they said they'd be quicker and cheaper than the competition.
Noa@StarkRG @barbra from my experience, management wants as much as possible as fast as possible, & employees can sense & fawn to match. That's why it's important to add buffer: the fawning will have things work at first before burnout makes everything fall apart. Adding buffer ensures no burnout & productivity continues longer & employees stay longer.
The reason that's not respected is that employees are seen as replaceable, especially as fewer jobs become available.
The Doctor
Marc Scheffel@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.
RussellThey don't follow it because they never got it. Most companies follow the peter principle: promote employees until they fail to train themselves.
A good developer being promoted to management rarely includes anything more than legally mandated training so they just keep doing what they've always done or retreat into their old responsibilities when things get difficult.
@zimzat @Sturmflut @jonm Well, that just sounds like terrible leadership. Which isn't surprising, of course.