On Culture and IT Management   8 comments

In my last post, I talked a bit about culture and how hard it is to assimilate culture. In this post, I’m going to talk about why assimilating culture, in practice, generally doesn’t matter.

We talked a lot about culture in class last night, which is a very interesting topic when held in a cross-cultural class… my current IS class has one Korean, one Nigerian, one Saudi Arabian, a Malaysian, some Chinese, a Jamaican, and four Caucasians. I don’t know everyone’s official status in regards to nationality (that is, I don’t know how many of the non-Caucasians are naturalized Americans vs. student visa holders), but everyone non-Caucasian has a thorough grounding in their native culture, so there were a lot of viewpoints in the discussion.

We were discussing a paper written in MISQ a little while back illustrating conflict problems in cross-cultural software development. Given the wide variety of destinations for outsourcing projects nowadays, some people might consider this to be a pretty important topic. I pretty much think it’s a bunch of hooey, and apparently most of my classmates agreed; the “culture of the geek” was way more important to IT workers, in our collective opinion, than anyone’s individual ethnic or religious background.

Yes, there are some obvious cultural norms that must be accepted when one is running an outsourced project, but there are cultural norms that must be accepted if you run in-house projects. Usually, these are either blatantly obvious conditions, or completely unimportant. For example, if you have a bunch of orthodox Jews on your software development team, you should pretty much plan that they aren’t going to be available on the Sabbath. Duh. If you’re in the US and you have a member of your team who hangs an Irish flag in their cubicle and wears a shirt that claims he’s a staunch supporter of “The Boys In Green”, you ought to consider it likely that he’ll be distracted during the World Cup if Ireland is in contention, and the odds are non-trivial he’ll be late to work on 18th of March, particularly if he’s young and unmarried. Unless you have someone who’s idea of “culture” is “being a racist”, the odds that this is going to really impact your team significantly is marginal.

A non-ethnic example: if you have someone on your team that has been married for, oh… say, 18 months or so, it may not be a bad idea to consider the fact that they may be asking for maternity/paternity leave, and that they may be severely sleep deprived for 4 to 8 months sometime in the next couple of years.

If you want to consider yourself a good manager, project or otherwise, you have to consider your employees as a bunch of individuals. Generalizing “by culture” is shorthand for saying, “I’m a lazy PM”. If you have a project that’s outsourced to Jamaica, shrugging your shoulders and claiming “everybody is on ‘island time'” is shorthand for saying, “I’m not interested in finding out more about how to motivate the individuals on my team” or, “Honestly, that 8 am meeting wasn’t really important, was it?”

Assimilating a culture fully (usually by immersion) is difficult and can have wonderful payoffs in understanding ethnic art, literature, and *causal* reasons for cultural norms. This is great if you’re a professor of literature, an art critic, planning a national marketing campaign in Swaziland, or just like assimilating other cultures (a goal worthy in its own right). It’s hardly necessary for your understanding of your team to the extent you need in order to motivate them. It doesn’t really matter *why* one of your team members prays five times a day, only that you take that into consideration when managing the team member. Consider it a necessary habit, and allow for it. If you’re looking to motivate someone, you don’t have to dive into their ethnic, religious, and social status like a researcher, all you have to do is talk to them.

Dipping into a culture briefly is a good idea, because you want to find out the obvious social norms. Thinking that understanding a culture is necessary to managing effectively is silly; understanding the people is necessary, but culture is only a part of the makeup of an individual.

I know pacifist Irish who don’t drink. I know Jews who go to Temple and eat bacon. I know Catholics who use birth control. I know Asians who are bad at math, but good drivers. There are independently-thinking Muslim women, Indians who don’t expect their children to become doctors or engineers, white people who can dunk, black Republicans, Montana Democrats, conservative feminists, golfers who are poor, and probably out there you can find someone under forty who doesn’t look like an idiot smoking a pipe. Take the time to get to know your people, and you’ll find lots of surprises.

Advertisements

Posted December 4, 2007 by padraic2112 in management, msis, social

8 responses to “On Culture and IT Management

Subscribe to comments with RSS.

  1. An important point that supports but qualifies your understand the individual thread. You had better tread carefully even asking about the cultural differences of a single employee. Really it is don’t ask don’t tell. Otherwise just in asking you are singling them out for said cultural differences… and presto… discrimination.

    Thems the rules and I can live with it. Remember in selecting your team not to even ask any of those personal life questions, or even follow up when it is volunteered.

    I have a couple experts that can weigh in here pro/con cultural understanding… you may know them.

    HAMMER, 25% Irish by blood. 0.00% alcohol by volume.

  2. So is hammer saying that 0% of his Irish blood has alcohol in it? 😉 I’d be more interested in find out what the ppm of caffeine is in his system.

    And Pat, do you really think it is “lazy” in grouping by culture? I have to believe that some PMs have so much on their respective plates that they can’t “get to know” every team member individually. Thus an overall “guideline” that provides some culturally understanding is better than none. IMO.

  3. I am estimating that it works out to no more than 0.16 BCC. That’s if I were to slam them all, taking my drinks over a period of four hours probably reduces it, but I don’t know the metabolic half life of caffiene.

    Oh, wait that was rhetorical? Can’t tell if the 😉 applies to the second sentence.

  4. > I have to believe that some PMs have so much on their respective plates that they can’t “get to
    > know” every team member individually.

    It’s okay to group people by constructed class. For example, I might have classes of people on my team that consist of “video game players” or “married, with children” or “unmarried, likes to party on the weekends”, or whatever.

    But putting people in a “Hispanic, therefore [this]” class or “Black, therefore [that]” class is not only eventually going to get you into huge trouble, it’s completely lazy thinking.

    “I can’t do my job properly due to time constraints” is occasionally a truism, but that means your employer ought to assume that you’re going to under-perform. That doesn’t mean you get to excuse doing your job poorly to begin with.

    I have this argument over and over again with some other systems administrators: “I have to do [this really horrible, insecure, un-reproducible thing] because the users are making me do it.” That’s garbage. The users can’t make you do anything. Management can’t make you do anything. You can choose to do something because you don’t want to go to the hassle of explaining why you’re right and getting buy-in from those people who have decision-making power – maybe that’s a political reality where you work, but that doesn’t give you the right to absolve yourself of the responsibility for the fact that you’re doing a bad job. You are the sysadmin. You’re the one who reads the CERT alerts and the security blogs and the O’Reilly books. You’re the one who is supposed to know what the hell you are doing, not the users.

    Giving every user “root” or “Administrator” privileges is a bad idea. It’s a bad idea for any number of reasons, all of which are listed in the SANS/NIST/ITIL/etc. documents, backed up by security literature and systems administration practice books everywhere. Systems are more likely to be compromised. Systems are more likely to be customized in a way that makes them difficult or impossible to replicate. Systems are more likely to be altered in a way that makes them break with your domain services. Sure, sometimes you may not have a good alternative, particularly on Windows machines. It may be a significant waste of time to figure out *how* to run a particular application without Administrator rights, because the application is written badly. Ok, now in order to do your job in a reasonable ROI way (and you do have an obligation to do your job in a way that makes sense for your organization), you may *choose* to give someone Administrator rights.

    But if you do that, you must acknowledge that they are more likely to have their machine compromised. They are more likely to customize their box in a way you can’t replicate. They are more likely to break something they’re not aware of (like, your logging or systems monitoring services)… and you have to account for that, and plan for it, and get everyone to agree that your plan is ok, whatever it is.

  5. I don’t know why we got the rant going, but you let ’em have it Pat! Just be careful, your counterpoint… married is just as potentially discriminatory as hispanic in good ol’ CA, USA. Just sayin. He works harder/longer or smarter/faster, ok to consider. He has kids, not ok to consider. Not to mention that Friday to Saturday time off versus Sunday off cultural bias of yours 😛 So don’t fess up to any of that here on your public blog.

  6. > He has kids, not ok to consider.

    It’s not ok to consider in terms of, “I don’t want to promote this guy to software team lead on account of he just got married and might have kids”. Sure. But “I want to keep this guy, and right now in his career path he wants to move to software team lead, and he’s qualified and will be good at the job, so I’m going to promote him… but he’s been talking with his coworkers about maybe having kids soon, so I need to account for that in my project schedule” is just sane management.

    Good people are good people. They’ll continue to be good people if they have kids, or get divorced, or have their house burn down during a wildfire. They’ll be more stressed and less effective, so it’s a good idea to plan for that, but you don’t halt their opportunities because they might become less effective later on.

  7. Yes, agreed. You’re pretty much okay there.

    Or he could be the guy who wants to get out of the house work harder, get promoted so the wife can stay home! I was almost that guy! You need to know! See, you may be applying your own personal cultural bias, or life history to that situation.

  8. > Or he could be the guy who wants to get out of the house work harder, get promoted so the wife can stay home!

    Absolutely!

    > You need to know!

    This is the crux of the situation; in today’s workforce (at least in the US), this is the sort of question many managers will *refuse to ask*, and a topic they’ll deliberately avoid, because they’re terrified that if they know more about their employees they’re opening themselves up to some sort of lawsuit. (More of a problem at large corps than SMBs, admittedly.)

    You have to know your people. If you don’t know your people, you’re going to be creating your schedules out of magic fairy dust. That’s no way to manage.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: