Overcoming Cultural Differences

Modern teams usually include people from a range of cultures, backgrounds, and nationalities. Frequently, team members are not even located in the same geographic region. All of these differences can impair a team's efficiency. Misunderstandings can easily become barriers.

Communication styles are different for people from different backgrounds. Here are a few frequently-noticed differences between Western and Indian team members:

• Indians engage in small talk less easily than their western counterparts. Some technical training courses actively discourage students from engaging in small talk in order to avoid embarrassing exchanges.
• Perception of time and schedules are different. When planning, Indian respondents typically do not include time to deal with any difficulties. Managers may need to probe to make sure contingencies have been forseen in the plan.
• People from the southern part of India use what is sometimes called the “Indian wiggle” in which the head is shaken side to side. This is frequently misinterpreted by westerners as indicating “no” (i.e., as in a western “head shake”), when it really indicates anything from “I agree” to “I hear you.”
• Indians frequently use a “wobbly yes” rather than saying “no.” Western managers need to watch for a less-than-firm “yes” and drill down if necessary.

These are all examples of differences in cultural norms. Unfortunately, it is all too easy to fall into the pattern of expecting that everyone else communicates the same way you do—after all, isn’t that what makes “sense?”

There are no rights and wrongs here, just differences. Managers need to learn to understand and value different team members from different cultures. And they need to set a tone within the group where people are not made to feel badly about who they are or where they live.

Folks are just folks. Technical people are, by and large, hard-working, dedicated people. It is not easy for anyone to achieve technical competence. Value your people, no matter what their background is. And make sure to promote a culture of respect and tolerance in your group.

Book signing in Jacksonville

I have a book signing scheduled in the Mandarin, FL Barnes & Noble on June 6 at 7pm.

11112 San Jose Boulevard Suite 8
Jacksonville, FL 32223

I'll be doing a brief presentation at 7pm, then signing and greeting after that. I'll post updates here as we get closer.

Setting Priorities

In an ideal world, every problem should be chased all the way to ground and completely resolved. But if you try to chase too many problems at once, you will be ineffective. It is only possible to really concentrate on one thing at a time; multitasking is a myth. The question is which problem is going to get focused attention first. In the real world, it is usually the case that we have to decide which problems are pursued first and most aggressively.

Two factors to consider are:

• The frequency with which events occur.
• The cost of each event

Counting the frequency is going to depend on having good incident reporting so that we can make valid comparisons between problems. Recurrences of the same problem may be described different ways, or even have different symptoms, so the analysis of incident reports needs to be sophisticated enough to group related incidents together.

The cost of each occurrence may be monetary, but it is most likely to be counted in terms of staff time to resolve and lost productivity while the symptoms are active.

From Techie to Boss Released!

From Techie to Boss has been released!

Sometimes it feels like non-technical managers just don't understand what we do for a living. The good ones try really hard and stand up for their team, but they just don't feel it in their bones. If technology is not stamped into your DNA, you just don't get it.

So that means that only technical people should manage technical people, right?

Here's the problem: technical people frequently do not make good managers. It isn't that they aren't smart enough; usually the best technicians are the people who are asked to step into leadership roles. But the skills that make a good techie are not necessarily the skills that make a good leader.

When you become a leader, the focus shifts. It is no longer about what you can accomplish as an individual contributor. You will be judged by your team's accomplishments.

Good technical people have developed good study habits, a sense of responsibility, and a solid work ethic. All of these are important, and can translate into skills that will help you be a good leader. But you will only be an effective leader when you inspire your team members to reach their potential.

Moving into a leadership role can be a bumpy ride. But it can also be hugely rewarding. Make sure to approach it from the right frame of mind. It isn't about you anymore. It is about your team.

This book lays out some of the lessons I have learned during my own transition from a front-line techie to a manager. The technical community has always been all about sharing what we learn. I look forward to hearing you share your own stories and lessons from your own journey.

Book Review: Root Cause Analysis by Duke Okes

Okes has done a remarkable job creating a book that is readable, concise and useful. There are several well-known books which will smother you with statistics and studies. Okes' book is a common sense introduction to root cause analysis that is general enough to be widely applicable, but specific enough to help most front-line people sharpen their troubleshooting process.

The examples are well-chosen and pointed, and the graphs and charts are explicit and well-explained.

If you need to troubleshoot or perform root cause analyses, this is an excellent book to keep on your bookshelf.

We Have Found the Problem, and the Problem is Us

I saw an interesting article in this week's CIO Insight about the causes and effects of stress for IT Workers. They report that the number one cause of stress for your employees is you.

(Well, I don't mean you personally. I mean "you" as a proxy for "us," aka "management." Or maybe I do mean "you" as in you. The answer to that question is going to take some introspection and maybe even some input from people we manage about what stresses them out.)

Here are what IT workers identify as the top causes of their stress:

• 29%: management
• 24%: inadequate staffing
• 20%: tight deadlines
• 15%: inadequate budgets for upgrades and projects
• 12%: users

My Manager Sucks

For the 29% who directly indict their management, I don't think you can get any more direct than that. We're probably talking about interpersonal conflicts with the boss, bullying, or harassment. Or we could be talking about lazy, ineffective or incompetent management. Any way we cut it, 29% of IT employees, when asked what makes their life suck, point at their manager.

If you are in this group, you need to fix it. Not only are you ruining your career, you are damaging the careers of the people you are responsible for.

Staffing Shortfall

That doesn't really let us off the hook, though. Let's look at the number 2 concern, staffing. Have we made sure that we have the reqs and headcount to support our responsibilities? Have we defined the workload and priorities in a way that our staff can reasonably be expected to carry them out? Have we filled the positions we do have with good quality people, and either repaired or discarded the dead wood?

If we have a staffing problem that is stressing out our people, it is likely that we have failed in one of those areas. Maybe we really aren't being given enough staffing for what we need to do. In that case, prioritize and assign work in such a way that people feel they have a chance to succeed. Some stuff is not going to get done, but at least the most important stuff will be taken care of, and your staff will appreciate that you are asking for something that they can reasonably provide.

Look for efficiencies and ways to do things more easily. Define processes and refine them. Sometimes you can organize things so that more can be done with less. But it is all going to start with prioritizing and sequencing your team's work.

Deadlines

Now let's look at the 20% that are talking about tight deadlines. Why are the deadlines tight? Did we commit to delivering something without understanding what we were getting our team into? Did we fail to sequence, prioritize and delegate work appropriately?

Tight deadlines and inconvenient scheduling are always going to be part of IT work. It may be the case that some of this 20% are maybe not well-suited for working in IT, or maybe they would be better off in a support than a project role. But I'll bet that a big part of this 20% falls squarely on the shoulders of their managers.

Budget Shortfall

A lot of the comments made about staffing shortfalls also apply here. If we don't have adequate budget to carry out necessary tasks, then we have failed to prioritize and plan properly. Sometimes these factors really are outside of our control. But a lot of the time, they are not.

Budgets are a pain, and nobody likes them. Too often, we avoid looking at them, and we miss opportunities for cost savings. When we do that, we contribute directly to the problem that results in the budget shortfall in the first place.

Users

Yes, even the so-called "PICNIC" problems (Problem In Chair, Not In Computer), are partly our fault. We have a responsibility to structure engagement methods and expectations in such a way that user complaints do not interrupt productive work.

Rotate bug management and incident processing between members of your team. Let everyone take a turn handling problem children so that everyone also gets chunks of productive time.

Nobody can be productive in constant interrupt mode. I'll bet that a big chunk of the people who reported "users" as the cause of the stress are people who can't put together a chunk of productive time because they're dealing with constant interruptions. Give them back chunks of time by rotating the user support roles and letting everyone else concentrate on bigger tasks for a while.

We are the Problem

Here's the thing: We were given a management position in order to make our team more productive and to create value for our employer. That isn't going to happen when your team is frazzled and stressed out. Take some time to think about your team's situation. If you see any of these problems gnawing at your team's morale, take action.

How Not to Think About Security

Hugo Teso recently reported on some pretty serious flaws in the security for airplane flight systems and pilot displays. He reports that using an Android device and some custom-written code, he was able to provoke actions by the flight systems and feed the pilot incorrect information. The Register has a pretty good summary of what Teso discussed.

In an interview with Forbes, Teso reported:

“You can use this system to modify approximately everything related to the navigation of the plane. That includes a lot of nasty things.”

Fortunately, The Register tells us:

Federal Aviation Administration and the European Aviation Safety Administration have both been informed and are working on fixing the issue.

That would seem to be an appropriate response to a flaw like that. You would really hate to think about al Qaeda sending a bunch of wackos with cell phones onto flights. And I don't think the FAA would seriously be able to take away peoples' cell phones on flights. Dealing with Alec Baldwin alone would stretch the resources of most Federal agencies.

Fortunately, the FAA has taken swift action to alleviate any concerns the flying public might have about some new-found sense of competency in that agency. The FAA reports that there is no real problem because the hack did not work when they tested it against a "flight certified" configuration.

The idea of "defense in depth" appears to have soared right past these people. If there is a problem in a component of an overall system, FIX IT.

Here's hoping that the FAA manages to stumble across a clue in between meetings about whether or not to allow people to bring fully-functioning bananas on planes.

Update

The app that Teso used is only effective against simulators. That does not mean that there is not an issue that needs to be resolved. The H Security reports that:

Teso says that the ACARS communication with a plane can be implemented locally via a software-defined radio system or globally via one of the two major ACARS providers, ARINC and SITA. The researcher added that a vulnerability would need to be found with the providers.

The manufacturer, Honeywell, is investigating to see to what extent the vulnerabilities in the PC product used in simulators are also applicable to hardware-based implementations used on planes.

Other media outlets, like Computerworld, are reporting on the differences between the PC simulator hardware and the hardware-based implementations. My opinion remains the same as it did earlier; problems need to be fixed. Working exploits depend on chaining problems together; a good security posture depends on removing as many links from the chain as possible.