rc3.org

Strong opinions, weakly held

Tag: management (page 3 of 3)

What The Office teaches us

Venkat Rao deeply examines the US and British versions of The Office and tries to distill a theory of management from them. Seriously, read the whole thing.

Update: The essay’s description of over-performing losers moving up to join the ranks of the clueless (if you read the essay this will make sense) reminds me of a story. There was a guy on our high school football team who wanted to come in first in every drill. If the coaches told us to take two laps around the track, he had to finish those two laps first. If the coaches had us pushing a sled, he’d push the sled the hardest. I won’t tell you what all the other players called him, but even at that early age, most people seemed to get that his effort was almost entirely misspent.

The guy wasn’t a great player, and the coaches didn’t give him any extra playing time because he practiced harder than he needed to. His extra investment in over-performing in unimportant drills didn’t make him a better football player. I wonder what he’s up to today?

Maker’s schedule versus manager’s schedule

Paul Graham explains on how people who make things must manage their time to maximize their productivity:

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

I think that the biggest sap on my own productivity is my failure to schedule my time to maximize it. I pride myself on being accessible and unperturbed by interruptions, but at the same time I think that keeps me from entering the mental state to really get things done.

More on disparate impact

Today I was thinking of disparate impact not in terms of employment law, but rather as something we’d be wise to look out for and avoid in a more general sense. In terms of employment law, disparate impact is any hiring condition that has the effect of discriminating against a protected minority without serving any essential business need, even if that discrimination is not intentional. (Disparate treatment describes intentional discrimination.)

Legal definitions aside, I’m fascinated with the idea of disparate impact. It has me wondering about it in a larger sense. For example, let’s say I manage a development team and we make most of our decisions during meetings where everyone argues their side and the person who makes the most compelling argument usually wins. Such a system privileges people who argue well in a group setting over people who may be more quiet. If decisions were discussed in email rather than in meetings, perhaps the best writer in the group would see things go their way more often.

In the future, I’m going to look out more for these types of disparate impact in organizations. What skills and personality types get an advantage even if they don’t provide any additional value to the business? Nobody is going to be busted by the EEOC for letting these kinds of situations arise, but they can make your company a bad place to work, and lower the quality of your decisions.

Automating accountability

In business, people talk a lot about accountability. In essence, it means verifying that people do what they’re supposed to, and addressing it with them directly when they do not. There’s a big problem with accountability, though, and it’s that it’s not easy to hold people accountable. Telling someone that they’re not performing up to snuff is one of the most difficult jobs a manager has, in part because it’s uncomfortable and in part because it has to be done in such a way that it leads people to improve their performance. (Unless, of course, they’re being fired. That’s even worse.)

World of Warcraft blog runs an advice column for guild leaders, and last week’s question was from a guild leader who needs to address a performance problem with a member of his guild. The details are amusing, but what really interested me was the proposed solution — using an addon for the game called Failbot.

Here’s the description:

Add some public humiliation to your raid! FailBot reports in raid chat (or another channel of your choosing) whenever a raid member “fails.” These fails are only things that are preventable by the individual on a consistent basis, so if someone’s name pops up it was irrefutably their fault, which makes it a great way to see who in the raid needs to improve without having to personally call them out.

I’m fascinated by this tool. It makes me wonder how we might develop similar tools for software developers. Clearly automated regression testing suites are part of the answer. I’m also trying release tracking tools like Pivotal Tracker.

I wonder what the similar tools are in other fields.

Links from February 3rd

A few links from the past few days.

Links from January 25th

Links for March 25

Newer posts

© 2018 rc3.org

Theme by Anders NorenUp ↑