How do we work on changing customer's perspective?
FWIW I worked with an eastern bloc country team (Europe) and it was top notch.
I see a lot of over complication in the code that our Indian developers produce. Lots of copy and pasting code around instead of wrapping in a common function and calling that. They setup weird data structures when simple arrays would suffice. Lots of redundant logic. They don't negate if statements, they use the else block and leave the if blank. It's just weird. It's not even laziness, there's way lazier solutions to the ones they provide. I'm tempted to think that Indian languages beget a certain style of thinking that produces this kind of code.
For that reason, most Indian companies focus on getting the cheapest price and do so at the price of quality.
If you want to do quality work, you'll have to hire more expensive developers and you'll be more expensive. You need to figure out a good positioning because you'll be more expensive that your local competitor, and less convenient than firms closer to your clients. Add to that the low quality image that won't go away until all your competitors start going for high quality development.
I'm just back from 3 weeks trip to their office. Here are my impressions:
* just a few of them (new team is about 40 people) are skilled enough to do the project work
* most of them never heard that people can google errors and check for solutions in the internet (I mean really, how can even a junior come with questions like "I've got an error X. please help me, I don't know what to do")
* they do not dig around. they were told to do X, they will do their best to do X. if it turns out that it obviously will break Y (and it can be seen from the beginning, or something similar might happen) they don't care. They have to do X.
* code quality is not high at all. sometimes they try to fit multiple workarounds to fix some consequences instead of digging around and fixing the root cause
* they stick to their hierarchical structure and rules. if manager told to do X, they will not doubt it for a second, even if it's something I would argue about (however I saw some rare exceptions)
* not all speak good English. some need quite a while to find the right word.
* if they will not change something in their workflow, I'm pretty sure they will completely screw the project quite soon after we quit.
This is my experience with new team. In the same time I would like to mention, that there are some good engineers over there and I had a good talks with them when I visited there another company for a day there, but not many of them. I can really feel the lack of qualified people.
PS. I enjoyed the trip a lot (even the kitchen sometimes). Most people in India are really kind and helpful. I managed to visit some interesting places and now have some nice pictures :)
1) Over-communication to a fault
2) Low code quality
I don't know how can you change my perspective, but I would suggest not trying to change the perspective of Indian agencies as a whole - but rather why you are different than the stereotypical Indian agency.
Perhaps the key thing is a tighter attitude to specialisation: most Indian (and, for that matter, far east Asian) development teams tend to have a "we can do everything across a billion platforms and techs" approach, where it might be better off concentrating your offering down to a few key techs, and really doubling down on the quality of those.
1) To address the over-communication we have stopped working on fixed price projects, and rather worked with customers as their extended team
2) We as a group of individuals are trying hard to change this perspective. Our Computer Science education needs to be blamed as well
3)I have created a very interesting slide on our deck
Once you are a developer you must not blame the education you received till now. It all depends upon how you work and learn after college/uni. Also, the quality of CS education depends a lot on what college/uni a particular person went to. Some places impart really good fundamentals and I am not talking about just the IITs.
But it's always the student (while in college) or developer (after college) who chooses and works towards the standard they set for themselves for how good they want to be.
3. As an engineer (who has worked in India almost all these 6-7 yrs after college and some outside exposure) I would advise adding one thing to your internal deck - work-life balance. I have seen many such startups/groups that begin with much enthusiasm and aplomb but often compromise on one very important thing - work culture and work-life balance.
Hell, a lot of them actually celebrate a bad work-life balance and I find that really depressing. Attended an interview recently with such a firm and when I turned down the offer citing work culture, after they pestered me for a reason, their retort was "Oh, we are anyway looking for 'highly motivated' engineers only".
So maybe add that. Because a bad culture does two things:
- You might never get best or even better talent to work for you or with you.
- It's affects your output and productivity. It's never more hour, more/better work.
2. I still believe the CS Education needs to be improved like anything.
Some Unis are picking up good practices but at large the fundamentals of programming needs to be taught in a better way.
3. 100% agree with you on work-life balance. We are doing our best to keep the workplace healthy, interactive & fun.
As a small team, our emphasis is never about more work but better work. We have always encouraged team members to speak at developer events, contribute to open source etc.
detailed descriptions of even minor things; to distract from the fact of very little being achieved.
Unnecessary details are relayed; implying little comprehension of task meaning and/or importance.
- Developers were almost completely illiterate when it came to basic things, like http vs https, using git, encryption vs encoding. That's just something I wasn't ready for
- Using old technologies, i.e. Eclipse for Android development when almost everyone is on Android Studio, having libraries which haven't been maintained since 2010 as dependencies
- Communication was horrible, I had to write 10-20 emails before I could get any answer
Other experience, estimates are wrong, filling in more hours than actually worked and they always say yes. But what they mean is we can't or don't understand what your mean and we will stall the project.
Me: Ok, and would you be able to blah blah blah?
Me: Great, and do you think that will be ready by blah blah?
Me: Fantastic. What approach do you intend to use?
Me: mutes phone, curses, unmutes phone, goes back to start
I've occasionally worked with some excellent individuals, but the aggregate has been poor.
My most recent experience with a team of this type repeatedly involved requests for documentation at a level of detail where automating the task would be less effort.
The biggest problems are cultural, but the perception is going to be hard to overcome.
I'll let one of our Indian colleagues suggest the best alternative here, as I'm sure they know more about the relevant Indian cultural points than I.
But even something like "Tell me how you will accomplish X?" or "Do you have any worries about doing Y?" tend to produce better India-US communication.
Another factor is that most of my encounters with such groups has been while working for organisations looking for a cheap option. I strongly suspect that this is common and results in hiring low quality groups with mediocre people - again tainting popular perception.
Usually the consultants/people-who-pitch at such dollar-hungry Indian firms won't tell you 'NO' because they fear they might lose you. People in-charge of saying 'YES' aren't often aware of the abilities of their team.
And, surprisingly, sometimes, the 'YES' comes out of plain politeness. In some occasions, they don't want to disappoint the clients who've exhibited a lot of trust on these folks.
So, when an Indian says 'YES', they correctly understand the liabilities & responsibilities that are implied, but they might not have what it takes to deliver on the commitments they made.
1. Saying yes to everything. Questions, estimates, analysis: everything was answered in the positive even when the facts were negative. I makes project control very hard.
2. Deferring to management every 10 minutes. On every call, meeting etc. Engineers were very much not able to make decisions by themselves.
Having said that, all men and women I worked with from these companies we're really friendly and certainly tried their best.
It's rather an untold rule across the industry to channel all decisions & difficulties via their manager.
I'll give an example - We once asked our offshore-engineer (contractor) to share their personal email ID for a github invite for we knew that he had one readily at his disposal. Using gmail for work is a big deal for IT offshoring companies. The guy, instead of sharing his concerns about his directives & security guidelines directly with us, called his manager who replied to our email asking us to stick to Enterprise email IDs.
1) Learn to say 'no' or 'we need to understand this better before we can give you a quote or a deadline — too often, way-way too often Indian outsourcing companies oversell their capabilities. Learn to say, 'this can be done, this can't be done' within the timeframe/budget etc.
2) Increase your prices, get more senior developers (increase their salaries). For most western companies even a 100 increase in price is still many times cheaper than what they can get and if you get better developers because you can pay more you will be able to better meet your deadlines.
3) Invest heavily in proper frontend people. Give them extra training if needed so they know how to write optimized code. There is a world of difference between solving the problem and solving it elegantly. All too often what you get back works but is useless because it's too slow.
4) Hire western project managers. Don't get me wrong I have worked with some really great Indian managers but understanding the western culture and expectations and being able to understand western expectations would remove 90% of the confusion that happens today.
5) Did I say, increase your prices and your salaries?
6) Be better at writing PRD's and set expectations, make sure you can meet those expectations and don't be afraid to push back on what's possible to deliver early on. The sooner a client knows there will be delays or the sooner they know their timeline expectations can't be met in time the better. That allows them to plan accordingly.
7) Did I say, Learn to say 'no' or 'we will have to look some more into this'
Ping me if you want more concrete advice, it's an area I care about a lot because I worked with Indian companies a lot.
Solving the quality, expectations and honest feedback would increase any Indian development house directly into a top-tier partner for me.
I have a competitor of yours trying to get a meeting with me. Their pitch is that I can have 10 programmers at $20/hr each, a 75% savings based on US programmers!
The problem is I want solutions, not man-hours!
That's because every single Indian dev agency experience I've had, has resulted in a net negative outcome, sometimes so bad we've thrown away _everything_ they've touched and started again.
A couple of ideas that might make everything "nicer":
1. Increase code quality. Commit to it. Understand technical debt and commit to reducing it. Refactor. Code reviews. Cite and apply industry standard texts like _Clean Code_ or language-specific texts (e.g. _POODR_ for Ruby). Test coverage, great documentation, highly readable code: they're not optional any more.
2. Go agile and lean. Don't expect BUFD. Realise the client is learning as they go too.
3. Don't take specs from a client and develop code that meets them. Develop the spec _with the customer_. Use BDD properly.
4. Realise there are many things that go outside the spec. Pre-empt. Don't wait to be told. Realise that functional requirements are less than 20% of what is needed to successfully ship a product. There are many things I would "just expect" a developer to do, but every time I've worked with an Indian dev agency I got exactly what I asked for, no more, no less, no common sense applied. Do I really need to tell you the "password" field should be encrypted at rest, and which crypto scheme to use? No, you should do that because it's basic common sense, and tell me what crypto you chose, and why...
5. Say "no" more. Say "I don't know" more. Say "we made a mistake" early when it's obvious you made a mistake. Don't pretend you/your colleagues are an "expert" in something if you've read one or two books or developed a couple of projects: you're still novices until you have 3-5 years experience of doing that thing. Embrace that, be honest about it, it's OK. Price yourself accordingly.
6. The sector tries to compete on price. Try and compete on speed or quality instead.
Our company started working with them because we needed a mass-production job done quickly: we needed a whole mess of paper health-care forms converted to Acrobat (pdf) forms.
We quickly discovered that this particular agency assigned a staff member who worked to really understand the forms and imagine the workflow of the people using them. The forms (PDF forms really are programs) we got back were excellent. They actually made the work of filling them out faster than the old paper forms.
So we inquired whether they could do other development work for us. That turned into a good relationship.
We went into the relationship not thinking "how do we get the cheapest possible programming labor?" but rather "how do we add to our company's capacity to get all these @##*% forms converted?". We started assigning low-risk tasks. And, after three years or so they were great colleagues.
We gave them good references and they got other work partly as a result.
We did daily "scrum" calls, early in the morning US time and at the end of their workday India time. Somebody went to visit them once a year. In other words, we treated them like colleagues. It's all about people and relationships.
I believe classic cost-driven "outsourcing" contract deals -- the kind of stuff that's driven by finance executives -- have contributed to India-based agencies' struggles with reputation. Would you hire a kid fresh out of Carnegie Mellon and tell him "you have your job because you're cheaper than our other developers?" No. So why would you say that to a kid fresh out of an excellent Indian university?
I believe the Odisha location was helpful, because turnover was lower than it might have been in Bengaluru or Mumbai.
Plus, Odisha is a really cool place to visit.
That's one story.
Successful agencies in the west pride themselves on being engineering focused and treating developers right. Treating them right means they are the cherished role in the organization, probably amongst the highest paid in the organization and roles are sought after by junior developers.
A common trend I suspect is cultural in India is that developer roles and most importantly senior developer roles are not prestigious enough. Titles seem to matter more and I witnessed many times competent developers are motivated to 'move up' into PM or manager roles either because of prestige or money.
Address this by creating a culture that attracts developers that want to be senior and grow within the role instead of simply a stopping point on their way (in their minds) to a CxO position that has the prestige.
If you can create a culture in your company where developers are cherished and highly paid, you will likely have higher quality as an output. Sure your price will have to be higher but maybe after a while you can beat your regional competitors on time too. Make sure this culture is actually in place and working before adding it to marketing materials.
Another aspect is payscale, you have to get promoted to non coding management roles to get a decent pay, So the priority will be getting to that level, not improving code quality and being a better developer
First of all, excel at communications with potential and existing clients. Have at least one person on the team to speak English on a native level. In your description, there are already quite a few mistakes and when freelancers and agencies apply to my gigs, I filter the initial messages out brutally. I don't even look at applications that feature spelling and grammatical mistakes and miss details I specifically asked for. Also, have a person on the team who has been exposed to the culture(s) of the region you want to sell to the most, in order to be able to e.g. say "no" more often and to also admit when you messed up.
Second, never approach a client with an opening line like: "Trust me Sir we are best developers we will do best work and give you cheapest price." You have no idea how many of these I get on a daily basis. You simply don't get the best people at the cheapest price. Define your target group and either sell yourself as a cheap, low-quality sweatshop or continuously invest in great people and training and sell yourself as one of the few exceptional agencies in India that actually delivers great quality.
Third, stop chasing short term profits. This is the worst aspect of doing business in India - most freelancers and agencies rather deliver bad work and get some money, then really putting hard work into in and building great relationships that will create lasting value.
Happy to give you more feedback, just ping me via the e-mail in my profile.
- The whole education system is totally messed up here, Things are changing slowly. the professors/lectures have no idea what is going on from rest of the world. the students are preparing for exams only in the last day. the exams are purely memory based. I did "Rote learning" during my school days.
- The interview process is highly questionable in most IT shops. Even Bill Gates can't get job here. (hint: its memory based interview process, it can be easily cleared by students who are well on it)
- There are lot of politics going on any IT firm (thats the worst thing)
- Most of the CEO do not listen. you have to follow their instructions.
- It was 2002, I applied my first job, friends who referred me for the job told me to change my resume to fit the requirement, instead of including my real skill set.
- It was 2005, my first interview in US, An interviewer who called me "how much US experience you have?" I told her "I do not have any US experience", I got lot of anger, what is going here?, I am doing coding for few years, now it has no value? latter I realized the purpose of the question.
- 90% of the students who are coming to IT industry are from poor/middle class families, they have lot of focus to improving their family, standards of life, unfortunately their skills/focus are not properly unleashed.
- Most IT people in India spending more time on traffic rather than coding.
- the list goes on. I do not see any use of listing/discussing these here.
What perspective are you trying to change here? This question is broad.
Rather if you are more specific and give one or two broad examples of what exactly happened vs what was expected by your clients and how to address them etc., you might get more useful answers.
Remember Indian IT companies vary from small boutique shops to mid-size to giants like Tatas. Company culture/ operating practices vary based on size and skill base.
The industry is quite mature and you may want to provide a little bit more information about your size/ context /problems faced, to get specific answers or recommendations.
I've had varied levels of success but the most consistently successful model has been a leverage model. By this I mean that there is one person in the agency whose primary (often sole) job is to manage the communication with the client. This person is representing the customer to the development team. The key skill that this person needs is that they are familiar with and can navigate the culture of the client as well as the culture of the development agency.
For Indian teams this usually has been someone Indian who has worked for a number of years in the US, the UK or Aus but it doesn't have to be. Note, I have generally worked for US or UK companies so YMMV.
Ideally, the go between is physically located with the client. This really helps in the US as the timezone headaches become an internal agency issue to deal with. If they're not co-located with the client then this can still work but the go between has to be really, really good.
My experience is that given clear instruction they deliver against those. We just had call this morning on commenting among other things. In any case, Hubspire has been a valuable resource. Don't believe there are tremendous cost savings though -- more about not finding resource in NYC.
a.) Picking good Project management tools (We use BaseCamp + Wunderlist, Asana + Skype, Slack + Trello, Jira + Skype)
b.) Most of the time we required Standup calls with project owner to discuss status & work ahead
c.) Proper documentation & project planning reduces time spent on phone calls & constant bugging
d.) Slack is considered to be distraction to your productive hours
These projects have been an ongoing effort to upgrade, resolve bugs and add new features.
The 'legacy' code just causes ongoing problems.
The main issue is everything is overly complex. They use 10x the amount of code that is needed for everything.
They also attack problems in really complex ways.
And they like to create really complex functions that are multi-use instead of clean functions that meet a specific purpose. It's not even really code-reuse or modular as they will pass a value to a function and then run it through a myriad of if statements to figure out what model it is and what should be done with it.
They also don't include much if any error checking, checking for objects before using them, etc so if anything unexpected happens a fatal error occurs.
I have contacted the original development shop, and contracted out some revisions to them. They do have one top notch guy, but he hands off work to other developers that aren't as talented, that's were the trouble creeps in.
To change perspective I would focus on writing cleaner code that is more bulletproof.
I totally agree that the quality of work is way to low.
I think that it’s up to the developer how well they write the code and develop themselves nothing to do with what majors they had in School. It’s all about handling the minutest details well and this is what differentiates a good Dev. It’s like carefully selecting the proper screws while building a drawer even though the screws might not be visible to the user.
I'd work hard to sharpen my skills. I'd find some way so let the world know about my skills. It could be through blogging, or through contributing in open source software, or any other way. When looking for clients, I'd find good clients who appreciate quality work (not every client cares about quality and not price). I'd work hard to build good work relationships with those clients. One good relationship goes a long way.
It is basically impossible to get any meaningful work done unless you have a person on site with the dev team.
You also need to write very very very detailed design docs and feature requirements.
If you absolutely must use services of these companies, try to get them work on peripheral features, instead of core application logic. You'll be minimizing long term technical debt damage risk to the project that way.
They are not a service based company, so this is not a cheap plug promoting them.
I see this question asking about what it's like working with India-based dev agencies, taking into consideration cultural differences.
It would be just as valid if asked about other parts of the world.
It's only a problem if agencies in India are highly variable. If there is little deviation from the norm, it's not a problem. As such, the potential that this kind of question might be hard to answer is conditional itself.
Anyway, this is a positive perspective customers have, and I admittedly benefit from it when doing business. In a lot of ways, the opposite can be said in terms of stereotypes for India, and so that's tough and I suppose what your question is about.
The thing is, even if perhaps I get an initial project in part due to a positive stereotype, that customer will not recommend me or use me again if I don't perform excellently for him i.e. making him better off through the interaction.
So that's what I focus on. And if you do that, in my experience, stereotypes won't matter at all. You won't be an "Indian Agency" but "Insert your company name" who does great work.
Some things I do to keep/maintain customers are: having very high standards of quality i.e. if a customer uses me I want them to remember me as the best contractor they ever used, they should be impressed at how clean/well-executed/designed/on-time the software delivery was. I also keep things professional, succinct and timely, and goal oriented and expect the same from the get go. Also if anything is not clear to me I make sure we clarify it and get on the same page immediately. Clients and you both hate wasted time/effort.
Finally, on the personal side I try to constantly self-improve and hone my areas of expertise so I can get things done more efficiently and be quicker on my feet and more creative/innovative with my solutions for customers. This is actually really big. Most (good) clients really really want someone who can think for themselves, is creative, and takes a problem and brings back an amazing solution. This can be difficult, I know, since a lot of clients won't give you enough information or even attempt to think their own problems through, etc. But with some you can help (being upfront, asking well-formed precise questions), and with the worser ones you can usually recognize them very quickly even in the initial project discussion and my advice is always walk away.
If you do these things, you will have absolutely no problems finding customers who love you and recommend you to everyone regardless of where you come from (at least IMH experience).
Best of luck.
10 to 20% of times we have failed miserably to satisfy customers needs.
You want fixed price, fixed DETAILED spec, fixed timelines and assume that you don't want to maintain the product afterwards. That's worked well when we've had quant calculators that just need to done one thing. Expect there to be a high management cost on your side.
Outside that, my experience has been pretty terrible and it comes down to a cultural desire to be positive all the time. Saying Yes all the time is a disaster, especially when dealing with non-technical business people. I'll give a couple of examples:
1. I've tech-Lead a large group (40+ but I interviewed more) of offshorers, the manager on the Bangalore side helped the devs through their coding interviews by recording my questions, working out the answers and handing them round. When I realised what was happening, I invented easy questions off the cuff and found the interviewees (on the other end of the phone) would pause and then give an answer they couldn't explain. I could even hear one guy typing in the question as I asked it. When we approached the Bangalore manager to sit in on the interviews, he said that he didn't see a problem, claiming over and over that he'd chosen the very best developers.
The CEO still went with the agency and I found that the few good developers that agency had moved on because they were offered more elsewhere, leaving with the knowledge I'd trained them with.
2. We expanded our team by bringing in an offshore team. The Indian provider sent 6 to 8 (can't remember) "senior c# .NET developers" over for us to train on the system. One of the developers didn't know how to open a solution in Visual Studio and asked me where the "Run" button was. When I showed him the CV that had been sent over for him, he agreed that it was his and confirmed that he had 6 years .NET experience. How you can code in any framework for 6 years and not know how to press F5 is staggering (this was back in the day when VS was your only choice).
None of the companies or managers I've worked with before would ever go offshore (outside of Europe) again.
> How do we work on changing customer's perspective?
A lot of this is cultural. What appears to be of acceptable quality to an Indian agency isn't OK where I am in the UK. Also, there needs to be balance between being positive while at the same time realistic. "Bending the truth" is part of the back-and-forth of Indian business but in Europe (and especially in software development), that's a disaster.
The best you can do is act more like a Western business and how their perspective changes of your single company.
You'll need to be clearer in what you're asking. Are you asking for opinions, or advice?
We also organize a monthly developer conference and emphasis on development practices + development tools on iOS.