When I began my career as a software engineer, I could not have imagined the important roles adaptability and soft skills would play in achieving successful outcomes for projects. In those early days, I believed that everything was black or white, that analytical and problem solving skills were my greatest assets, and that communication should always be direct and concise. Reality showed me a different picture.
I joined Flow Traders in 2011 and I immediately found myself working with a wide variety of people, not just the machine in front of me. I had never considered that I might need to sell a solution to someone, or that I would need to explain the architecture of a big project to a non-technical person. These were new skills that I needed to learn. In this article I will share my experience of working at a company where diversity feels at home - the perfect place to develop communication skills and learn the value of our differences.
Flow Traders is a trading firm, a liquidity provider to the major financial markets.
Flow Traders is a company with offices in different places around the world. This results in a remarkable amount of diversity - people from different fields, different backgrounds and expectations, different cultures and even different time zones. I love that I can enjoy this diversity every day, working directly with different departments and offices. While it can be a creative environment to work in, it is also challenging, as all that diversity can lead to misunderstanding.
As with most engineers, I have the tendency to use short sentences to communicate facts and solutions. This concise approach works well with other engineers, but, as I began to work with people from different fields and backgrounds, I ran into difficulties. I quickly learned that different people have different needs when it comes to communication and misunderstanding can easily occur if we are too focused on our own goals, expectations and views of a solution. Sometimes people need to hear a story, be given examples, or even have the same fact presented in a variety of ways before something is completely clear. This doesn't mean I always need to tell long stories, but I do take time to check that what I want to express is understood and that I understand what is said to me.
Listen attentively before providing of a solution. This helps me better understand the needs of the audience and gives me a different perspective that I can use to design and implement a creative solution.
Consider what a colleague understands from each concept. How would they usually deal with a situation and what is their ultimate goal?
Use words from a colleague's vocabulary. It is important to use the right words, with the right attitude and at the right time.
Each of us has a role in the company. I am a software engineer because I find solutions, a trader is a trader because he finds opportunities, a manager is there to keep both views aligned and to lead us towards reaching our goal. We each have our own job, we are all different, but we need to work together. From my personal perspective, I have found that working closely with colleagues from other departments and offices can lead to better solutions and more gains in business knowledge.
For example, a colleague who works at the support desk might ask a lot of questions about an application I am building and I might have already explained these things ten times to everyone. I now understand that a support engineer has their own, unique needs. To effectively answer the questions they receive, they need to feel confident and trust that an application performs correctly. I learned to take time to consider how I can best meet their needs. Answering these questions early on could make my job easier in the future:
What do they need to know?
Is the information they need clearly documented? Do they have access to the documentation? Do they know where the documentation is?
Take a different situation. I work in close collaboration with a colleague in an office across the globe. They are usually available at the end of my working hours, say from 3 PM. They might need my help to figure out a problem with an application developed by my team and I might need their help to find a problem. To make the most out of the time our schedules overlap, I will organize my daily work to allow full focus on the task we need to work on together, during the available hours. I may even consider shifting my working hours for a couple of days. Of course, this might be seen as interfering in one's work life balance, but I find it an advantage to have the flexibility to choose to do so for limited intervals of time.
Understanding why we each do what we do is important when working together. I find it insightful to see things from a different perspective, to look beyond the view of an engineer (having the solutions in their back pocket), and to consider the needs of the end user or the person who made an initial request for an application or feature. Our applications must often cater for differing needs. For example, the data provided by an application might be viewed by non-technical traders as well as used by other applications in the application landscape. As the developer, I need to understand the requirements of every user, which would also include a non-technical trader accessing a web UI and any other applications using the data.
Whenever I start a new project, I spend some time sitting next to the relevant person to understand where the need is coming from and to see how they work with the data that an application provides. Shadowing a colleague's work helps me understand the problems they face every day, which is useful when proposing a solution. For example, if I sit with a colleague from the compliance department, I will learn how they work, what they do, why they have to do it the way they do it and where I can help. After I have completed my part of developing an application, I can directly collect feedback on the user's experience regarding what I have built. This allows me to learn and measure my own growth.
I also take a similar approach to solving problems faced by colleagues. Whenever possible, I experiment on my own to better understand their situation. The difference between theory and practice can be striking. When reading the theory, it seems like you understand, but put that same theory into practice and suddenly you see things differently.
I try to ask myself they following questions to see things from each perspective:
What does the trader see in the UI that he uses? Maybe he only sees a part of what I know is there.
Is there another layer between the data my application provides and what the trader actually sees?
How does the user want to use the data my application provides? Do they have enough information available to do that?
What will the other application do with the data it retrieves?
The nature of our business means people have to be competitive while still working together as one team to achieve our goals. When a company encourages an entrepreneurial and innovative culture, people have the chance to think outside the box and express their ideas, not only within their specific field of expertise, but also by contributing to the company as a whole. Being a global company brings a lot of diversity that encourages us all to build our communication skills.
Since everyone in a company is open to share their work with you and since we are actively encouraged to sit next to the end users of an application we build, we can change our view point easily. The interaction with end users makes the work more interesting for me. I can see how a piece of code that I write is more than just a piece of code. It makes the work of my colleague easier, it contributes to the team's goal of being better every day.
At the end of the day, what remains after a day of work is more than a piece of code that we write. It also has to do with the experiences that we had while writing it, what we learned in the process and the accomplishment that we made someone's life better.
by Davide Corda
by Zita Szőcs
by Radu Cristea
