The following interview is part of the Omixon interview series that we are conducting with Key Opinion Leaders at Omixon. The next interviewee is the leader of Omixon’s R&D team, Márton Pogány, Head of Software Development and Project Manager, who gives us a glimpse of his project management techniques and the roles of his department.
What is the difference between a software developer, a programmer, a software engineer, and a coder? Can we use these words interchangeably?
In short, all expression means the same, but if we would like to be more specific, software engineer is a bigger set or category which can contain functions like developing, programming, coding or designing. Software engineers design software just like artists: have strong basics on the technical field and capable of seeing the structure of the future software and they can also tell if it will function properly or not. The rest is basically down to the other specialists to work it out and bring it to life for the customer. Software engineers usually take functionalities into consideration just like, future development possibilities, switch-off modules, data layers and bases, back-end logic, data storage or front end design.
Why Omixon? How did you get to Omixon?
After spending a few years at multinational companies my aim was to work for a small firm instead. Before I joined Omixon, I had been working for companies like Ericsson, the NNG or the CitiBank so I got tired of being a soldier at gigantic companies, so I was looking for a smaller firm to work for. However, comparing to several interesting and fate like stories of my colleagues, how they became Omixon employees, mine is quite regular and boring: I applied for an open position and I was selected. I started here as a Project Manager and later I was appointed to be the Head of the Software Development Department. It has been 1.5 year now and I joined the company 2 years ago.
What does a software development manager do? Could you describe what you do exactly?
To be honest, the answer is quite complex and takes time to explain, but I will try to shorten it.
Basically we, software developers, work in cycles. Each project has different phases : planning, developing and testing phase. At our company, the Technical Lead and the Head of the Software Development are responsible for designing a schedule for a certain development. If once a schedule done, a ticket is created in our project management system containing all inputs for the development team to get the job started. In the development period, developers just do their work: they develop.
Then comes the test period, when several specialists search for bugs in the developed software element, inspect if they function well, and compare it to the original description. Afterwards, they start to test all alterations together to see if they have any non desired effect on each other. Finally, the most important step is to check if there is a regression (undesired result difference) at the end results. If there is no regression, the development project was successful. However, if there is a slight undesired deviation that has negative effect on the result the development process must be reviewed and started over again.
Though, it is widely recognized in cyberspace, that the perfect software simply does not exist, we have to strive to develop the best analyzing software which exists on the market.
What is the best about being a software engineer/developer?
The most positive part is that I can create non-existing tools have never been invented before contributing to the healing of other people. This is a great feeling in itself!
On the other hand, we have to consider the huge responsibility laying on our shoulders. Not just what our policy and vision contains, but we always remind ourselves to think of the impacts of a certain modification in our software as it will probably affect the lives of several people. We must be aware of working for a good purpose, and it goes with responsibilities to patients. I do not regret coming to Omixon, and having a position like mine is a privilege.
Tell me the Good and the Bad parts of your position!
I really enjoy working here because I have a say in decisions and the management listen to the department heads’ advice. At the same time, it is quite easy to identify with our mission, which says “we are committed to improve our patients outcomes” as there is a goal in common we can work for. Working for a good purpose is an important factor which motivates me to do my best every day.
There are routine tasks to do in our processes, that are an important part of the job, but maybe not the most interesting or exciting. One of them is the quality requirements which are very strict, and our department has to perfectly meet the requested conditions from quality point of view. Although this is a burden on me, but is a huge advantage for the company. We are able to raise the quality level, which makes the products more acceptable to customers.
Also, working with developers, who are people with differing tastes and thoughts, can be challenging. Often providing mediation between them, and the product management, seems to be a mission impossible at first sight, it takes a huge amount of time and energy, but it is very challenging and never boring!
In the world of developers there are many, many small changes and tasks which have to be done, but cannot be seen even once it is done. Fortunately, Omixon’s management pays attention to small details and do not forget about acknowledging everyday work as well as big achievements.
What makes a good department manager? What is the secret of being successful in project management?
I think, it is essential to be able to communicate well in every situation and to make decisions at the right moments. If a manager possesses these features he is more likely to be successful.
It is worth noting that leading and managing people is a separate profession from our core tasks. Of course, terminology differs in terms of professions, but if you are appointed to be a manager of others that is not a vertical up-grade, but rather a horizontal, meaning that you made a step sidelong. You become responsible for others work and operation, you have to teach them, listen to them, manage their needs and requests, moreover you have to escalate and delegate, while you are doing your own work as well. It definitely takes a lot of energy and adds to your daily work routine. Essentially, it also means that you get more workload. Though, I might not be the best subject of this question as everyone experiences it differently.
How do you coordinate your team? Usually software developers have rather introverted personalities, so participating in meetings and discussions could be a challenge for them, though it is a must if you are a member of a team. What methods do you use to make them participate?
In my opinion, it is very important to look for the reasons of people’s behavior. Employees must know the reason why they have to participate in certain meetings and what are the benefits of spending time with meetings for them and the company. By explaining the purpose of a meeting you actually give a chance to employees to make the meeting more efficient and successful, providing a feeling that they could contribute to the meeting with their ideas. On the contrary, if you do not highlight the benefits of a session, and your team is not actively participating, they will regard themselves as an insignificant factor, and become demotivated. However, if you listen to your team members and reply to their ideas they will be thankful for sure. In the world of geeks, people only see their own sides and opinions, as they are not really intended to share it with others if they are not asked. You can ease this situation by opening doors between people, giving them space and time to share their thoughts.
In this field of software development, tiny ideas can be a huge help. Some of our developers suggested to put “traffic lights” into our software which was a brilliant idea. By decreasing the sample of the data to analyze we managed to shorten the decision making time at the end saving time to our customers. Apparently, we managed to make the software more efficient with the advice of our developers, so we had a cake and eaten it! Nonetheless, communicating our negative feedback is also an unavoidable action to keep the employees in the loop.
Working in teams, depending on each other: not a piece of cake, but it is necessary to engage the other teams to create a well designed product. How can you work it out?
Our product is undoubtedly complex consisting of 2 main elements: an assay kit and analyzing software. There is a hard link between these 2 parts, so consideration has to be made if there is a change in any of the elements that may affect the other. Feedback comes from the customers and we are here to satisfy their needs, so we need to talk to customer facing teams, who are in contact with them. ( So please, if you have any questions, let us know and we got you covered! As my team consists of non-biologists, only developers, we often contact the bioinformatician team who are hybrids, like superheroes: half informaticians, half biologists and have the (super)knowledge to highlight any problems which are caused by a poorly designed specification. The proper functioning of a software can only be designed if we know how it is used in the real world. Simply, if we know which feature has the highest probability of occurring, we can change the order of buttons with the sequence- the most common one will get the first button and the second most common will get the second etc. Ikon set can be also mentioned here as bioinformaticians will tell how many and what kinds of icons needed to identify features of certain loci. The product management group help us in ergonomic and required functionality questions or our Field Application Scientists can be mentioned who deliver hot and fresh information and feedback directly from our customers. Neither coordination nor mediation is easy, but this task is also in my shoulder and I have to live up to the expectations.
Do you have a technical roadmap? What is that exactly?
A technical roadmap is a special time line where we pin the most important cornerstones of a certain product. Main features, launch dates and expected changes are also marked. Type of qualification is identified on this tool as on our products list contains two types of items: Research Use Only (RUO) or CE marked. The product manager and the research and development team work it out together and all have to give their consent to be finalized. This is a living scale what is subject to change as time passes and the products are being developed constantly. After the road map is finalized and accepted by all departments the software development department calculates an approximate deadline and plan the developing process. It is undoubted: strong cooperation is needed among different teams to work together on a “never-ending” project.
So, what are the biggest software development challenges and how can you overcome them?
Solving software development challenges never comes easy. Main advantages of this company are its small size and flexibility. Small size causes the constant changes of the requirements what is difficult to tackle. Replacing missing specialist when they get sick can cause difficulties as each and every team member has a key role at the department. If we have all the necessary keys in the keyholes then we can work properly. I can just repeat myself: our team is just too tiny to work without the involvement of everybody. Today finding the best experts and professionals who can meet the requirements and fits to a team as well as a company by their personalities is a challenge demanding a good portion of luck as well.
Finally it is worth mentioning that the time factor is one of the crucial points as we are intended to facilitate the treatment of today’s patients not only future ones. Considering our capabilities we are aiming at contributing to the improvement of our patients outcomes as much as we can.
We are certainly aware of the fact that our entire company is the size of a department of one of our competitors, yet we are ready to compete with competitor giants while we are trying to show the World how to accomplish big things, even when you are small.
Is there anything at your work you are proud of?
In terms of our software, we managed to sacrifice time and energy- besides other tasks – to reshape it a bit by improving its outcomes, so we can meet future market needs and demands.
Regarding the Omixon laboratory, it was a huge success in our scrapbooks as we managed to built it up from zero, and it was only a side project next to our main tasks and to-dos. Our laboratory research team contributed a lot, and they provide expertise to help me and the management. In the meantime our quality team became a solid department, and I could support them on their way from the software side, which was a good feeling, because: