Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A bit of organizational sociology: most people silently group their employees into two categories: people they pay to do things that they can't do (Type I) and people they pay to do things that they don't want to do (Type II). If you're Type I, you get a lot more respect than if you're Type II.

Managers who can't tell the difference between good and mediocre programmers lump them all together into Type II. Type II employees are evaluated based on their availability rather than their expertise or excellence. Contrary to stereotype, managers know that status pings cost a hell of a lot of time. That doesn't mean they're going to stop doing them. If someone is seen as a Type II employee, then it's seen as better to have that person available but running at 25% speed (you can always hire more people).

The issue isn't that managers are idiots who don't know that interruptions (especially the emotional kind, which status pings often become when a person is asked to justify time) waste time. They aren't idiots, and they do know that. The problem is that managers (and not just them, but everyone in the mainstream business culture) tend to correlate social status and competence at close to +1.0, so they assume that people who are getting hit with frequent interruptions aren't very good anyway.



Welcome back!


> managers know that status pings cost a hell of a lot of time

BTW, I learned a good hard lesson about this. I had a long ongoing argument with one of my first managers that I could get 25% more work done if he'd just leave me alone until the end of the week, and that it was too much overhead and interruption for me to show my progress twice a day. I was working in CG films, and they wanted twice-daily renders of our shots.

I was wrong. Managers need status. Not twice a day for most code work, that's not normally reasonable, but on a basis more frequent than coders want to provide them ... it has to be before the work is done, not when they feel ready to present.

The reason is because everyone in a room can agree after an hour of talking in detail, on precisely what needs to happen, and then a week later find out that every single person in the room actually had a different idea.

It pays dividends to proactively provide the status managers need before they ask for it. Fend off the unexpected or interrupting status pings, and give them what they need.


It sounds like -for programmers- a good compromise might be agreeing with your manager that the last fifteen minutes of each work day will be spent on detailed status updates, and the first five will be spent on checking email to ensure that the hasn't been any miscommunication.


Re: silent grouping, that is my experience, it pays to be aware of it, and pays to aim for Type I.

But Re: assuming frequent interruption reflects negatively on performance, that is contrary to my own experience. I'm trying as hard as I can to rule myself out when I say this, but my friends and coworkers all suffer from more interruption the more knowledgable they get, and the more valuable they become to the company. This is one of the most damaging aspects of interruption culture IMO -- it often hurts the people most capable and willing to help the most.


>"all suffer from more interruption the more knowledgable they get, and the more valuable they become to the company. "

Well, in that case they're valuable for the knowledge they provide for their coworkers, rather than the work they produce. Being a bit in this situation, I'm leaning more and more into letting my boss know that this is something I need to do full-time, and simply not get any work done because of it. I think it's a huge boost to the team having someone knowledgeable to guide and mentor them.

However, I doubt it'd fly so well with the bean-counters.


>A bit of organizational sociology: most people silently group their employees into two categories

Is this from a book or research? If it is I'd love to know where I can go read more about it.


IRL




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: