• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Breaking down Managerment/Engineer barriers

 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
On my current project we're using an agile process and have created the concept of one unified team working together. Unfortunately there's a still a divide between business and engineering. The vast majority are contractors (most of whom are H1B's from India hired by the contracting firm). While I want all engineers to interact more closely with business, the divide is more pronounced with the H1B's. Clearly three issues at play are 1) they're contractors, 2) the business folks average being older by about five years, 3) the business folks are technically more senior in terms of official hierarchy (even though we don't really draw a distinction within the team). And for the H1B's there are cultural differences.

With my US teams I have had more success getting everyone to work closely together. Here, the business team is inexperienced with software and needs the help of the engineers, but the latter just seem to want to wait to be told what to do. heck, whereas on US teams the engineers often feel that they're smarted than many other people and often provide "helpful" suggestions to other groups, here, when we need it,t he engineers see issues, but have no desire to speak up.

To be clear, the head of the project is friendly and has never chastised anyone for being wrong or for suggesting that someone else is wrong; there isn't a culture of punishing people. The architect and the lead (one is an employee and one a contractor) but show initiative and propose alternate solutions, and even question some of the business objectives, all of which is welcomed. We can't seem to get the rest of the team to do the same.

Any suggestions on how to bridge this divide? What have you personally experienced in the past that has worked?

--Mark
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That sounds like one of the more common - and more valid - complaints about offshore talent and one I've personally experienced. Indian, Chinese, and - even in their own unique way Japanese - workers have a different cultural attitude about their managers. And, in fact, about the stratification of society as a whole. American developers tend to suffer from delusions that they actually are management, and frequently have to be reined in. On the other hand, Asian developers traditionally have been trained in a rigid academic environment that discourages random free-thinking in favor of giving the "right" responses to questions. I believe some considerable discussion was given to that issue right here not so long ago.

Once they leave the academic world, workers move into an environment where leadership carries almost an aura of divinity. It is expected that a leader give orders and the followers shall carry those orders out. If the leader fails to give sufficiently detailed orders and academic knowledge fails, the process is in jeopardy. It's all well and good to say that there's no "punishment", but that's the American view towards the Asian. The Asian view is more that it is the leader's responsibility to anticipate the needs of the workers every bit as much as it is the workers' responsibility to faithfully and accurately carry out the dictates of the leader. To imply that the leader was insufficiently competent to anticipate the workers'
needs would be an insult to the leader. A leader who asked for advice could be considered at best as having asked rhetorical questions and at worst as someone not worth following.

In a sense it's American Management's Dream Come True - as a nightmare. The perfect IT workers - developers who realize they are workers and not management. People who will do what they're told and like it and not come up with all sorts of awkwardnesses. And they don't, but lo, the awkwardnesses arise anyway because software development may be something done on mindless mechanical devices, but development itself stubbornly resists being mindless and mechanical.

My own personal experience with offshore developers was very much like writing a program in a high-level language. You fed in specifications, you got back code. The code was generally high-quality, but they did exactly what you told them to do, and not what you wanted them to do.
Just like a computer.

Enough. Rightly or wrongly, that's my perceptions and it's what I'd be basing my own strategies on - at least until I learned better, and in any case, YMMV, every situation's different, stddisclaimer.h, etc., etc., etc.

One possibility might be to have the offshore team pick a spokesperson and encourage them to brainstorm amongst themselves for an hour or 2 every morning. Or at least at regular and frequent intervals. Perhaps if only one person were "at risk" it might be easier to get better feedback. Anonymity has its advantages. Then again, they might end up unionizing. BTW, an offshore lead is not the best person to be heading this process up, since that just aggravates or even justifies the reticence of the lower-level people. In fact, if there is an offshore lead, the mere proximity of a person of authority is likely to chill the process.

Another possibility would to attempt to get the passive group to play the roles of the business users and have them attempt to give feedback as avatars of the users. Though I'm less sanguine about the likelihood that that approach will work.

Unfortunately, the strategy most likely to succeed would be to actually fly over and personally interview for the desired traits, unless you are fortunate enough to know someone already over there who can understand what you want and do it for you.
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To be clear I've run offshore teams before understand the underpinnings of the behavior, but I'm at a loss of how to fix it.

We do have a retrospective every 2-3 weeks and the engineers do identify issues that need to be addressed. However, while the team has learned to identify the issues, they (meaning both sides) have not been as strong correcting the issues. I can mandate meetings but that really doesn't strike me as the right way to generate the necessary interactions.

--Mark
 
Ranch Hand
Posts: 687
Hibernate jQuery Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mark Herschberg:
To be clear I've run offshore teams before understand the underpinnings of the behavior, but I'm at a loss of how to fix it.

We do have a retrospective every 2-3 weeks and the engineers do identify issues that need to be addressed. However, while the team has learned to identify the issues, they (meaning both sides) have not been as strong correcting the issues. I can mandate meetings but that really doesn't strike me as the right way to generate the necessary interactions.

--Mark



Make the contractors feel, they "OWN" the solution as much as the others. The issue with contractors is because of the nature of the contract the feeling is more kind of a person who is hired to do stuff rather than get stuff done.

This feeling sometimes leads to a feeling of "what's in it for me, as at the end of the day I am not going to get any credit" feeling. This also takes care of people making an effort to provide genuine suggestions and not play spoilsport in brainstorming meeting by coming up with irrelevant ideas.

When a person knows that it�s his/her responsibility for a task, he/she more or less speaks up when something is wrong or when the person knows the task can be done in a better fashion.

I am not suggesting it�s the case with your team as I do not know enough, but getting the people on board is a behavioral exercise rather than a management one.
[ July 31, 2007: Message edited by: Devesh H Rao ]
 
Author
Posts: 3473
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is not easy to solve these kinds of problems.You can interview a candidate for the desired traits/cultural fits by using SAR (Situation/Action/Result) types of questions.
 
Ranch Hand
Posts: 999
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
These problems frquently arise even while doing offshore projects.This happens because either:
1)Contracting company has told them to mind only their work,no less,no more.(So if I am .NET developer I need exact specification what should I code and what not.If something changes later I am not responsible). or

2)There is a fear that if (s)he takes the initiative and latter something fails (s)he will be asked to go out of project.or

3)As Tim said Asian mind set.(Contrary to Western work culture,I have seen many people(us,Indians) work(and perform) better in chaos type environment.)These contractors may be new hence might take some time to adjust to new culture.

I believe its combination of all these three which prohibits them to take the lead/initiative.
 
reply
    Bookmark Topic Watch Topic
  • New Topic