Dealing with US Clients: A Developer Perspective

‍Get to know key players and personalities

‍

US clients tend to be very organized in terms of knowledge and hierarchies. In this way, the concept of “key players'' is essential. They are the experts: The people in the company who know the most in their area of coverage.

‍

It's important to know who they are, what they know and how they work so that you can solve difficult situations in an efficient way.

‍

One of the first things you need to do is to ask your leaders about these Key players. Some companies also have confluence pages or another wiki system with the Key players there with an organization chart.

‍

Investigate before you ask

‍

US companies typically expect developers they hire overseas to be self-sufficient. They want us to be able to solve problems on our own. This does not mean you don't have to ask questions; this means you should be able to use the necessary resources to gather information about the problem and ask the right questions to the right people. 

‍

This becomes important if the question is being asked to the key players. Key players are, in general, busy people; they don't usually have time  to discuss minor things, they need you to get straight to the point

‍

This doesn't mean you should be afraid of asking them, but you really need to investigate before, have a good idea of the problem and more importantly present the question with possible solutions.

‍

Let them see you

‍

When we work with US clients, there is a very important difference: they don't see us. Most of the time, depending on how the meetings are handled, they don't know our faces, they just hear our voices and read our chats.

‍

In this way they have very limited visibility of ourselves and that can be good or bad depending on how we handle it.

‍

If we limit ourselves to just say our daily report on the daily meetings and complete our tickets, then, they would measure you only by statistics. This developer has donde 5 tickets in the last 4 sprints. He has done 15 story points and has 2 declined PRs. This isn’t necessarily bad, but can become a little too structured and a bit stressful.

‍

We need to show ourselves and let them see you, let them know the person behind the developer, let them know your passion, your willingness to help, your drive to evolve.

‍

Go further than standups. Participate in every meeting you can. Share your thoughts, make an interesting comment, offer your insight, maybe even find the right moment to crack a joke. Be yourself.

‍

Try to be active and get to know the whole picture. Ask for more questions. Ask if there is any help you can give. Ask interesting technical questions to your leaders and at the same time try to talk about client requirements with your PM.

‍

Understand your place in the company

‍

As a remote developer for a US company, it's extremely important that you understand what your role is and what’s expected from you. This is also important for you, because you need to understand yourself what your job entails, and what your responsibilities both are and aren’t.

‍

Generally speaking, US companies tend to have very efficient and well formed structures and procedures. In this way they've taken the time to add structure and define the roles of each person in the company, and the responsibilities they want to give to every one of them. 

‍

Developers are expected to complete tickets, to get involved in solution making, to generate ideas to solve requirements and to be able, from a technical point of view, to do anything they are required to do: from writing a HTML portion to integrating with a 3rd party API. (Of course depending on our seniority and developer role).

‍

Developers are NOT expected to solve general problems of the company. They don't expect us to tell them how to do things, how to architect solutions and how to change the whole company technological ecosystem.

‍

This is not a bad thing, but surely is something we need to have in mind when working with US clients. Don't expect to be able to cause a revolution, because you will fail, and you will feel bad and at some point frustrated.

‍

Do your job to the best of your abilities, grow as a professional, and let them know with time that you are a capable developer with the power to help the company evolve even further and that your input is very valid and rich. 

‍

In time, with patience, with evidence and with results you will get to the point where you will be the right person for the job. Maybe, you will even become a Key Player. But first, do the tickets, adapt yourself to the company technical environment and work culture, and try to be the very best version of yourself. 

‍

Understand the product

‍

Many times developers tend to just think about programming. This is not necessarily bad, they are programmers after all and coding is what they do. But it can become really positive really quick if we get to know the product we are working on.

‍

Understanding the client's needs will give us the opportunity not only to be able to complete our job in a much more knowledgeable way but also will give us the opportunity to propose things, to generate better solutions, and to gain more information about the company’s goals and vision.

‍

In time, if a developer understands the client needs and can collaborate efficiently with a PM to translate these needs into development requirements, then it is likely that this could become an opportunity to become a leader of a project or even of a team.

‍

Of course this depends on your goal, maybe you just like to focus on programming and that's fine.

‍

Take the opportunity to learn

‍

Learn from your leader, from the PM, from the PO, from your manager and from your teammates. Understand they know more than you, have more experience and they are in the place they are because they earned it in the past. 

‍

Take the time to learn about the product, about the technologies they use, and about their industry.  Make the most of what you can learn from the company and their employees.

‍

Respect your workload

‍

US companies like to take care of you. They understand that a developer’s job relies on their mind, and that difficult problems need to be solved speedily and efficiently. 

‍

For us to be able to do that we need to have our own time, we need to rest, and we need to have a clear mind. They know this and encourage it, basically because this will be good for the company at the end of the day.

‍

Following this line of thinking, treat working overtime as an exception, not a rule. Typically a client isn’t going to want you to work extra hours unless explicitly requested.

‍

Dont do extra hours yourself. It wont make any difference if you say in a standup that you have been working during the weekend to finish something because that is just not what they expect from you.

‍

You might think that is a good thing, because you are giving extra effort to the company, but it can actually be a bad thing...

They will start thinking: Why did he need to work on the weekend? Is it because he wasn't able to complete the job during regular hours? Is it because maybe he is not doing the work as expected? What do we need to change to prevent this situation from ever happening again?

‍

Believe me, they will not think: “Wow, thank you, you are awesome”

‍

Conclusion

‍

US companies can differ greatly from Argentinian companies.

‍

They have a very different way of working, they are strict in terms of timing and responsibilities and they like to do the things in a very structured way. Understand this and use it to your own advantage.

‍

My time in Devlane has helped me to understand this. If you are looking for a trusty partner that knows how to work around US companies, Devlane is for you. We are a boutique software development company that offers a special treatment to our clients.

‍

If you are looking to hire IT software developers or develop a software product consider us as one of the main Latin American companies that are available.

‍

If you wish to know more about, visit our websit or directly contact us here.

‍