Competency was probably the most important trait. A boss without a clue was easy to dupe and avoid, but also a pain when you were actually doing plenty of work. A boss that knew what was what would be on your case if you slacked, but also super relaxed if you were producing to expectations.
Clear communication was also critical but it was even more important to be measured in the volume.
Very true. We struggled with this at a past company. Most engineers were inherently honest and hard working, but maybe 1 in 5 were constantly playing games to convince their manager that they were working harder than they really were.
Managers who were formerly engineers had no problem spotting this. It was the managers with non-technical backgrounds who struggled to gauge if their employees were really working hard.
My workaround was to coach non-technical managers to pick up clues from the person's peers. If you privately ask 3 random team members to estimate tasks and 1 person constantly gives estimates 10x longer than anyone else, that person should be watched closely for performance issues.
It also helps to group people together to finish tasks, then ask each of them how it went in private direct conversations (your schedules 1:1s). The person's honest peers will give strong hints that another person isn't pulling their weight.
Trust your employees until they prove themselves untrustworthy, but be careful. We had at least one confirmed situation where a remote employee took another full-time job but didn't quit our company. Instead, they worked on doing the bare minimum to keep their manager satisfied so they could collect paychecks until we were forced to fire them. I suspect this play will become more common now that WFH is on the rise.
So I had a boss who would call a group meeting, bring up a problem that needs to be solved, and ask people who can do it. One engineer would explain that this is a research-level AI problem that would take years to solve, another engineer would say he's going to have some time to hack on it later in the week, and a third would say that he can pull an all-nighter tonight and solve it. So the manager would pat himself on the back for a job well done. He created a spirit of healthy competition in the team, he exposed the slacker (the first engineer) for what he is, and he squeezed the third engineer for all he got. A year later, the team would be back in the same place, with the manager calling a meeting and bringing up the same problem, which as it turns out the users are still suffering from and higher-ups in management are pestering him about again.
I thought the third engineer pulled an all-nighter to solve it?
There's a habit of technical folks to come to conclusions they shouldn't, and this is a perfect example. It generally manifests itself in interviews where the technical interviewer will come to conclusions that don't necessarily follow, only in this case it's not in an interview, but with respect to fellow co-workers.
I mean, you can see the hubris in the poster, who would have you believe that they're somehow "training" their management to "spot poor co-workers". Yeah, ok.... sure you are. Because managers are like monkeys apparently?
That's some dark humor, there.
But in terms of "exposing" how many managers in the industry think -- so true, so very true.
But apparently, this is in the opposite direction of what you are talking about. That said! If I were to pad my guesstimates, then it could legitimately look like sand-bagging. I don't know that there are any easy answers. I am trying to become more accurate (if for no other reason than not having to work over Christmas holidays to keep up with my promises), but estimation is hard!
An interesting experience is to estimate things in your own life. You plan to do something, write down when you expect yourself to finish it. It is quite humiliating to notice the effort you put into convincing yourself that you are more productive than you actually are. Unlike with job, you can't make the excuse that impressing other people is a good strategy. Yet, it can take a lot of work to stop doing that.
2hrs === 4 days.
A week == 2mths.
Anything past that would never get done.
He was a cynical bastard but not a bad guy and sadly he was in a lot of dysfunctional environments not that far of the mark.
The golden rule of estimating is to measure past estimates and use them as a multiplier in future.
The platinum rule is to stop estimating because it's useless.
20*2*1.2 = 48
20*2.2 = 44 // I, also, was confused myself at this point
2 *1.2 = 2.4 // not 2.2If a manage doesn't pick up on it early enough, then shit will eventually hit the fan.
e.g. there probably wasn't video chat. So how did you communicate? Were you coding? What were tooling like for coding remotely back then? etc etc
I worked at the end of a Telebit Trailblazer, so I had a 19200 baud link to the internet. I remember emailing myself GCC - staged the tarball on a remote host, uuencoded it and sent it home as multiple email messages.
We mostly did stuff via email, with the occasional conference voice call. I had to learn to restrain myself and not try to solve user problems when I first saw them - because of the distribution of time zones, I would tend to be the first person awake.
This was definitely coding - we were selling and supporting Interlisp-D and its many derivatives.
When I worked for other people, management spent a lot of time with requirements and specs before implementing, which often resulted in mismatched software expectations. Agile gets poo-poo'd now, but it was a revolution at the time
When I was doing my own consulting, I always did my best to find local clients for remote work (often building e-commerce web sites when the competition was still using FrontPage) because it was preferable to be able to call the client or meet in person to discuss the inevitable requirements snafus.
Honestly, it doesn't seem that much different now. Humans are generally not all that great at communication. The tools we have today make a dent in that problem but there's still significant unresolved challenges.
When I'm leading teams, I tend to spend a lot of time on teaching people to communicate more effectively and creating processes to enable it. It makes things go more smoothly than trying to be the central hub for all communication.