You need to grow your business outside of your home country. But you don’t have 10 years to do it. You have 6 months, at best.
And you know that learning a language takes forever. You don’t have time for that.
Fortunately, there are four things you can do that will get you the result you need, and it will only take you half as much time to get it.
Because at a certain level, it’s not about the language anymore. Your language skills are already good enough to get the job done.
So it’s not about acquiring more tools. It’s about putting the tools you already have to better use.
Don’t spend another year wasting time, and getting only frustration in return. Let us show you how to put to work the tools that you already have.
Who hires us and why:
- A Dutch civil engineering firm that is pitching a commercial development project in Riyadh.
- A Turkish software startup that wants to grow its sales in Europe.
- A British cloud storage company that wants its CTO to present better to the board.
- An Italian steel manufacturer that wants to increase its credit line with a German bank.
- An American e-commerce company that wants its software engineers in India to communicate better with warehouse managers in California.
Basically, it doesn’t matter whether your industry is software, electricity, construction, or something else. If you’re a non-native speaker who pitches X to Y, we’re the ones who help.
Companies we’ve worked with:
Why the focus on engineers?
Engineers have a special need when they are talking to others: They are technical people speaking to non-technical people. Getting those non-technical people to buy in is much easier if the engineers “talk to the dog” — speak in the language of the audience, not in the language of engineers.
Engineers are also one of the most globally-mobile groups. They tend to be produced, disproportionately, by middle-income countries, and then be sought after around the world.
How do I know if my engineers need communications assistance?
Your engineers might need communications assistance if you experience one or more of these situations:
- Your RFPs are getting turned down late in the game.
- You would like your engineers to represent the organization in public.
- Other departments groan when they hear the engineers will be presenting.
- You feel like the engineering voice is being drowned out in board meetings.
- You are trying to raise money, and an engineer is part of the pitch.
What makes for a successful client?
Over our years of doing this, we’ve seen three traits that successful clients all have. They are:
- A history of serial problem solving.
- A frustration coming from one of life’s slaps in the face.
- The fear of god (an external force that makes them want to solve the problem that #2 brought to the forefront).
Look inside yourself and get in touch with these three traits in you. You’ll get a lot more out of it if you keep them close at hand!
If you want to hear more on that subject, listen to this podcast episode:
Work samples:
A required slide for most proposals. Typically, a budget committee will review at least 5 proposals at every meeting, so they’ll need a way to quickly remember which project was yours.
The team slide is an essential part of the deck when presenting to most budget committees. After all, they want to know who is going to be spending their money.
The project timeline slide is a key part of any deck. In this case, the client wanted a simplified Gantt chart that would show just the major steps of the project.
Of course, every budget committee wants to know what something will cost. That’s their whole reason for existence! This was a cost projection for a simple project: Some on-prem servers and per-employee software licenses.
Somewhere, usually in the pitch’s early slides, there will need to be a shot of the product in use. After all, you want the budget committee picturing what their money is going to buy. Words are necessary for this, but they are not enough. You need images too.
One of our clients was pitching to a budget committee that had been burned by projects staffed by inexperienced implementation teams, so it was especially important to represent the combined experience of this team.