Beyond Do's and Don'ts

Being involved in multi-cultural, cross-border projects is much more common these days than it was the past. So how has our ability to work effectively in this environment evolved in recent history?

I can recall the first project I had in a foreign country. I did what a lot of people did, I learned what you should do and shouldn't do in that country. For example, in an Arab country, it is considered impolite to shake hands with someone using your left hand (a "don't"). Similarly, in India, where it is common to eat with your hands, using your left hand to eat is also considered impolite.

So while learning the do's and don'ts will keep us from making a fool of ourselves, we need to go further to work effectively with these cultures. Some areas to focus on include;

• Problem solving - does the culture you are working in put more emphasis on facts or on logic/reasoning? Do they come at the problem from different angles or try to focus in on just one solution?
• Governance - how is power shared or controlled? Are people punctual or not? How do they approach risk?
• Relating - are tasks more important or relationships? Are individuals or groups more important? Are communications explicit or implicit?

Understanding the answers to these questions will help you understand how you should work with other cultures. If you know a culture appreciates explicit communications, you will know to get to the point rather than indirectly address an issue. So next time you are going to work with another culture, take the time to get beyond do's and don'ts.

Technical Debt

So I started a new program a couple of weeks ago. Typically I get involved with new clients and help them build their first set of business processes using our software. This project is different, the client has been using our software for a number of years and part of my job is to take of the operations/maintenance of a number of applications.

As my team started looking at these existing applications, they came across a lot of "technical debt." The applications were developed and enhanced by a number of different developers with different skill levels (some with low skill levels for working our our products). So we have a lot of code that's going to be hard to maintain and enhance.

It's a tough situation. The client uses a charge-back system to charge the business units for development, so we don't have money to just go in and completely re-factor an application, even if it needs it badly. On the flip side, both new enhancements and maintenance take longer because of the debt we've inherited.

For now we're going to have to live with it. We'll try to pay off the debt slowly by cleaning up parts of the code as we do our development or maintenance. I think the client is starting to realize the cheap solution for development wasn't necessarily the best.