Working With a Remote Developer Team

Thanks to the internet, the whole world has changed a lot during the last 20 years. New professions have appeared and the earth has become more international. There’s much more cooperation between people from different points of the world nowadays than ever before.

These changes have influenced the life of software developers as well. Can you imagine developing without an internet connection? No? Me neither.

There’s another big change: Earlier developers worked either alone or with people sitting in the same office, but today, it’s different. You can have team members from all around the world.

More and more companies have offices in multiple countries, and they are building international teams. It is totally normal to work with colleagues from India or from Russia, even if you are sitting in Germany or in the U.S.

I have also worked with remote teams on several projects, so I already have some experience with it. During the previous day, I was working with developers from India and Ukraine. I met a lot of nice people and learned a lot about their culture, which made this cooperation very nice and colorful. However, such cooperation is never easy.

It always takes a long time to set up an effective team structure, and both sides need a lot of patience due to the different work habits of the remote team members. All things considered, I really enjoy working in such a mode, and I hope I will have more chances for that in the future.

Why Companies Opt for Remote Developer Teams

I see two big advantages of this working model from the company’s point of view.

The first advantage is that it is really difficult to find good developers in places like Silicon Valley or Germany and at all places where there’s a lot of tech companies around. The big tech companies are usually located near each other to be able to set up good connections between them. On the other hand, there are several countries around the world that do not have their own big tech companies, but they have plenty of software developers, so it’s better for the big tech companies to build up parts of their teams in these countries.

The second advantage is all about money: There are the so-called best-cost countries, where there are developers who work for less than half the price as workers from other countries, and with such a salary, they still make far over the average in their country.

I don’t know how long this working model will stay so popular, but it is just becoming more and more popular every day. If you are a programmer or you are leading a programmer team, there’s a good chance that one day you will contribute on such a team.

Advantages as a Developer to Work With a Remote Team

When I was a child, I always wanted to have friends from several different countries. I was curious about how they were living and what their habits were. Later, as a student, I had a chance to meet some people who came from other countries, but still not many. As I started to work at an international company, where we worked with remote teams, I achieved what I wished I could as a child. Thanks to this working model, I gained several colleagues from all around the world. They usually visited us, and I also had a few chances to visit them to travel to such countries where I had never been before. I learned a lot about their culture and habits. I also learned different ways of thinking, which helped me a lot.

So, working in such a structure gives you a chance to get to know people who are living far from you to taste their food, to get familiar with their culture, and sometimes also to visit their place. Traveling around the world on the company’s dollar sounds good, right? Furthermore, it is also a good chance to learn languages, especially to learn English, since that is the language used at most of the companies.

Main Challenges of Working With a Remote Team

As usual, along with the advantages of this working model, there are also several disadvantages. But let’s think in a positive way and call them challenges instead, and see what solutions are possible.

One of the biggest challenges I experienced is the limitations of online communication. If you are working in the same office with your colleagues, you can just ask them anytime if something is not clear—you can show them your monitor, get quick support, and it is really convenient. You can also hear what your other team members are talking to each other about, even if you are not directly involved in the discussion, so later, if you are facing the same issue, you know who can support you.

Furthermore, a lot of really informative discussions are happening out of the office: in the canteen during lunch, in the kitchen next to the coffee, or at an after-work program in the evening. These are all ways of communication that cannot really be done with a remote team.

Also, quite often, the remote team members are not native English speakers, which can also cause some misunderstandings.

Another issue with communication is the time difference.There could easily be several hours’ time difference between the two parts of the team, so the working hours do not really match.

Last but not least, I need to mention cultural differences. If your team members come from a different culture, they can have a different religion, and different habits.For example, it was really surprising to me when all my team members disappeared for a while after lunch. Later on, they told me that they were praying. It was a normal daily routine for them, and something totally new for me.

There are also differences in the working culture. For example, I’m working in Germany, where I have to give three months’ notice of when I’m resigning my contract—more than enough time to find someone new to the position and transfer all the knowledge. As I was working with people from the Ukraine, they had a notice period of two weeks. From the two weeks, it was quite normal that they took some holidays. So they had maybe six or seven more days in the office. You simply had no chance to keep the project stable if a key member had just left.

Best Practices for Working With a Remote Team

How is it possible to work effectively and solve so many challenges? Try these tips that have proven successful for me throughout my experience.

Meet Regularly

At first, it is really useful if the members of the team are visiting each other sometimes. It is good to meet personally with your team members so that you can also get familiar with the culture of your colleagues. The communication is much better between people who know each other.

It is a good idea to organize business trips for the ramp-up period of the project and for bigger workshops. On the other hand, such business trips cost a lot, so most companies are really limited.

Trust in Your Teammates to Work Well

Based on my experience, the most important tool needed for cooperation is trust: You need to trust in the knowledge of your colleagues, and you need to trust that they will achieve their tasks before the due date. If you are checking the status every day, that will just demotivate the remote team.

As you start to work with a remote team, first try to understand their working style and let them understand your working style. After that, try to set up your cooperation in a way that fits all working styles.

Always handle your remote colleagues as equal partners. Try to set up a core working time when all parts of the team are in the office. Figure out the time frames when the remote team is normally not available (due to lunch, praying, etc.) and don’t call them during that period. Also, synchronize your national holidays.

Clearly Understand the Tasks

In most cases, one part of the team has more information about the tasks because they have more experience with the topic or they are at the same place with the product owner, who can answer all questions regarding the tasks. This part of the team is responsible for transferring all necessary information for the remote team.

To avoid misinterpretations of the tasks, the best practice is to use written communication forms that are visible to the whole team, such as ticketing systems, chat groups, and e-mails. Provide all the information to the remote team, let them read through it, and then let them ask questions. If you are not sure about something, check the points with the product owner before answering them. Always document all questions and answers in written form.

If you are in the remote part of the team, always try to get a clear understanding of your tasks. If you don’t understand, collect your questions and send them to the so-called “local” team. Do not start to work on your tasks until you are 100 percent confident as to what you really should do. It is also good advice to create a short implementation plan and discuss it with the team before the implementation, especially if you need to change multiple components in the code.

If any questions come up while working, feel free to write to your team members. To clarify such questions, a short call with screen sharing is one of the most effective ways.

To integrate all the changes on the codebase, it is a good practice to have one dedicated software integrator who reviews all the changes, integrates them into one code, and tests it.

Learn to Work Effectively With a Remote Team

Working with a remote developer team has become much more common in the last couple of decades. Communicating with coworkers from around the globe is quite challenging, but it is doable if all parts of the team are handled as equal partners.

If there is respect and trust within the team, and the communication is done in a clear, well-documented way, there is no distance too large to work effectively and productively with your team members.

I’m new from the university - Let’s understand different roles

At most of the software companies there are several different roles: project manager, team manager, software architect, lead developer, technical leader, software tester, scrum master, product owner, junior software developer, senior software developer, system engineer, requirement engineer etc. If you are new in the world of software companies it can be quite difficult to understand the meaning of these roles. It’s because sometimes the same role has different names at different companies or the same name means different role. Plus some of these roles are really similar to each other, but still not the same. In this chapter I’m trying to give an overview about the meaning of these roles. But at some companies it can be different.

Trainee:

This is normally a position which you can take over as a student. Normally it’s a part time job and you can support the developer team with implementation of tools or smaller features. This is normally the first step of your carrier.

Junior software developer:

A junior software developer is normally a software developer who has less experience and can work independent on features and software components, but still need regular support and leading from the more experienced colleagues. You can take over such a position normally after finishing your studies/working for a while as trainee. This is really a good position to learn a lot about software development.

Senior software developer:

It’s up to company, but normally your next career step after being a junior software developer is something called simply software developer or you are going to be immediately a senior software developer. A senior software developer is an experienced software developer (usually has at least 5 years of experience), can solve problems independently, can choose between technical proposals, has a good overview on the overall development process, can make solutions for new problems as well. Normally a senior software developer should be able to support the junior colleagues.

Software architect:

A software architect is responsible for the design of a software. That means a software architect is creating software design and makes sure that all the implementation is following the design (normally it’s done by code reviews). A software architect needs to have a very good overview, needs to know the related technologies well.

Technical leader:

At some companies each project has a technical leader. A technical leader is normally someone who can take technical decisions and who is technically responsible for the product. A technical leader is most of the cases overtaking the software architect tasks as well.

Lead developer:

Lead developer is typically a role at smaller companies. It is usually a mixture of technical leader and project manager.

System engineer:

The system engineer roles exist usually at products which has a close relation to the hardware (embedded development etc.). A system engineer is usually not deep in coding. A system engineer needs to plan how the whole system will work: why inputs are provided in which format, what are the states of the system, which outputs will be provided, what are the corner cases and limitations of the system. The system engineers are using quite often some modelling software (Matlab etc.).

Requirement engineer/Buisness analyst:

A requirement engineer or buisness analyst needs to understand what is the expected behaviour of the software in different use cases and document them in a clear, non-ambiguous way. They need to think about corner cases as well. Requirement engineers are usually not deep in code. This role is quite often overtaken by system engineers.

Software tester:

A software tester is someone who is creating test plans based on the requirements of the system and after that runs manual tests or implements automated tests and book the result in the correct format. A software tester needs to understand the requirements well and needs to think about corner cases. Most of the testers know some scripting language and test framework for automated tests.

Project manager:

The project manager is responsible for the planning and tracking of the project from budget and time point of view. That means: it needs to be planned: what will be done, when and by whom and the project manager needs to track it. If something is going wrong the project manager needs to identify and help to resolve the issue (like needed trainings, missing inputs etc.). Usually the project manager has direct connection with the customer and needs to report the state of the project to the higher level management. The project manager is responsibility is that the project needs to be done in time and inside budget. At some companies the project manager activities are shared between multiple managers (one is only responsible for time planning and tracking, one is responsible for the budget etc.). The project manager has normally some technical knowledge, but most of the cases the project manager is not deep in code.

Product owner:

Product owner is a role in scrum projects. The product owner is the one who has a good understanding of the project goals and requirements and who is creating clear user stories from these requirements. The product owner is setting the priority of the user stories and well. The product owner is always available for the development team but is not part of that.

Scrum master:

Scrum master is a role in scrum projects. A scrum master is supporting the team to keep the scrum process. A scrum master can be a developer as well in the same time.

Team manager:

A team manager is responsible for a bigger team and multiple project. The team manager is responsible for hire new colleagues, do regular feedback meetings with the employees, identify needed trainings and send the right colleagues to the trainings, supporting employees to reach the next step in their career path, motivating employees, identifying and tracking goals for the employees, do resource plan between the projects etc. A good team manager has experience in development, project management and has good interpersonal skills.

I hope it helped a bit to understand these roles. But as I said there can be big differences between companies.

10 Points to make your ramp up faster at your first workplace

Don’t think that you are the best

It can be that you  were part of the best students at the university and you could achieve all tasks there. It is also most likely true, that due to you fresh studies you are more up-to-date with the newest technologies than you colleagues. But your colleagues has multiple years experience in the field you are working in. It was always a bit strange for me, but as a student I thought that I’m good and as I started to work I was encountered as a beginner. It’s totally true, I had no experience, so it took me much more time to resolve tasks than for my more experienced colleagues. Luckily it changed with time. That also happened that there was some kind of used practice at the company which seemed to be totally useless for me. I just clarified it with my mentor and I understood their decision.

To summarize this point: you will be encountered as a beginner and you are a beginner in fact, count with this fact and if you are doing well you can change it with time.

Be patient

As you are joining a new company at the beginning you need to wait a lot: wait for your hardware, wait for you licences, wait for your access to the source code and wait until your colleagues find time to clarify topics for you. You need to be simple patient. Your colleagues also have their tasks, most of the cases with a due date, that’s their first prio. You can be sure, they will support you as soon as they can find time.

Pay attention on what your colleagues are doing

You can also use the time, until you are waiting. You can also learn a lot without blocking your colleagues. Simple keep an eye on them and try to understand what and how they are doing. You can also check their commits in the version control system, check what was their task and how they solved it. You can also check what kind of meeting are they attending and what is the scope of these meetings. So that you can learn really a lot without blocking others.

Collect keywords and google them

At the beginning for sure you will hear a lot of keywords, technologies which you have never heard before. If you hear such a keyword just take a not and later if you have free time google it and try to understand what is it about. If it is still not 100% clear you can of course ask someone, but then you can already ask more directed questions. It makes a much better impression. So instead of “but what does MVP stand for?” you can just ask that “I’ve heard that you are using the MVP pattern in your architecture, could you please clarify how is the presenter layer working?”. Sound much better, right? You can reach this point after 10 minutes on Google.

Collect a list of questions

Do not block your colleagues with each and every question. First try to collect a list a questions, make sure that the one has some time for you and go through on all questions in the same time. Take notes about the answers. It is much more effective, than just asking something in every 10 minutes. And it is also much more effective than “please tell me everything about your project”.

Be patient at working on boring tasks

Most likely at the beginning you will get some boring tasks. Do your best on them and so that you can get much better tasks soon. If you are not achieving the boring tasks with good results you will never get more interesting tasks.

Communicate your issues

Let always your team mates, mentor and manager know what are your current issues. For example if you are blocked, because you don’t have access to the code, don’t just sit and wait, but let your manager know that you have this issue and it blocks you at work.

Build connections

For building your career it is really important to know the right people at the company. During your first weeks try to get know as much of your colleagues as possible. The best way if you are doing some short talks in the kitchen, during lunch and so on. Always try to figure out who is the person, what is their role at the company and for which project are their working for. You can also take later on some short notes (but don’t do it during the discussion!).

Do regular feedback to your managers

That’s normal that at the beginning you don’t know your managers, so that you also don’t know their exact expectations. It is a good practice to ask them for a feedback regularly (maybe once a month) in the first period. So that you will be able to see if you are working in the right way or not.

Be hard working

In the first month do really your maximum, to make a good impression.

+1. Pay attention on work-life balance

This is a special point and it is maybe does not really stand for the first months. I just realized that there are a lot of workaholic developers, especially young ones at their first job. This means the one would like to fulfill all the expectations. That’s why he is working a lot, does regular over hours. So that their manager will give them more and more tasks, so they are working more again. And they are starting to cancel or shift their private programs, choosing to work in the evening instead of meeting with their friends and so on. This kind of working style is leading easily to a burn out, so try to avoid it! On the other hand it is also not always the right way to build up a good career. You will considered as the guy, who is overtaking every shitty task and not as the guy who can achieve every difficult task. And it makes a really big difference. Always set up the priorities of your life and keep them always in front of your eyes.

Efficient home office

One big advantage of working as a software developer is the possibility of working from home. Although it is possible practically most of the companies does not allow to do it for all of their colleagues and there are also many developers who doesn’t like to work from home. The companies are usually arguing with non-trackable and not effective work and with pure communication. The developers has often also problems with the same points and they also think that is a bit depressing to work always from home.

My first experience with home office is coming from right the beginning of my career. It was the last semester of my bachelor studies. I only had to go once a week to the university, the other days I was just working on my thesis, which was a software with documentation, and next to that I was a trainee at a small company, where I was working in remote mode. I got my tasks and once a week I needed to present my results. So I had two big topics to work on from home and my time schedule was really flexible. First I thought it will be a really great time. After some weeks I realized that it is not good at all. In the morning I didn’t wake up in time, as I woke up I didn’t start to work, I rather watched some series. I started to work just right before lunch, then I got hungry soon, so I took a long lunch break. In the afternoon I tried to concentrate on working again, but most of the cases some friends just called me to go out somewhere and I could never say no for such invitations. So I went out until late, thanks for that next morning I couldn’t wake up again. Usually the day before my meeting I realised that I didn’t have any progress, so I was working all night long. Some week before the due date of my thesis I also realised that it’s not in a good shape at all, so I was working all weekends long on that. After a while I was totally stressed, because I always had the feeling that I should work. Next to that since I had a lack of experience I often faced with technical issues and since there was no one around who could help, it took me long hours to find a solution or I needed to wait until the next week meeting and in the meanwhile I was totally blocked. All things considered it was horrible.

After this experience I tried to avoid to do any home office, I was rather in the office until late or requested for a holiday if I had any issue at home. The years flied and 5 years later I found myself in a totally different situation. In the meanwhile I collected a good experience in software development, I became father and with that I also changed my lifestyle. At the company where I’m working I had sometimes chance to do home office and in the previous time I did it a lot. At the beginning I felt myself a bit uncomfortable at working from home, but it changed, now I really like to do it and I realized that I’m more effective at working from home as sitting in the office. But to achieve it there are some points to follow.

1. Do follow a preset daily working time
   As normally you have any kind of working time what you are following (like you are arriving at 9 and working until 4.30 in the afternoon) set up your working time at home as well. You can save your daily travel time, it is already an advantage. So let’s decide that for example you start to work at 8 o’clock. Then really wake up at 7.30, have your breakfast and start at 8. Be strict to yourself. And let’s concentrate on working until the end of your working hours. Out of your working hours be also strict to yourself: do not work. That’s needed to be able to make a difference between your professional and private life.

2. Do have your proper workplace at home
   This is the point what I couldn’t achieve in our current flat, but it is also needed. You should have a seperate working place at home, the best if it is a seperate room, where you have your desk and a proper working environment with all your needs: good chair, big monitor, sunlight, proper temperature etc. Be here during your working hours and don’t be here out of your working hours.
   
   
3. Change your clothes
   

   
   Of course it’s nice to be whole day long in your pyjama, but in that case you have the feeling that you are at home and not at work. Change your clothes. Of course you don’t need business outfit at home, but at least take a T-Shirt and trousers.

4. Your family needs to understand that you are not at home, you are at your workplace.
   
   
   It should be also clear for your family that you are not at home during your working hours, even is physically it is not true. You don’t have 2 minutes to help, you can not answer a short question and you shouldn’t be disturbed.
   
   
5. Keep on communicate with your colleagues
   
   
   It is also important not to be totally isolated from your colleagues. Keep on communicating them with some chat client or through phone. It is also good to have a daily status meeting which is done through phone. With that you and your colleagues have the feeling, that you are not working alone.
   
   
6. It is not working without enough experience
   

   
   The other thing I realized is that as a junior programmer at the beginning of my career I got stucked really often. That time just googling did not mean always a fast and working solution. But to ask a more experienced colleague helped really fast most if the cases. From home you can of course write to your colleagues or call him. You can also use a screen sharing application. But it is simple not so effective. That’s why I don’t suggest working from home for juniors.

7. Set up your daily targets
   
   
   It is also a good strategy to set up your daily target in the morning, what you would like to achieve until the end of the day. Don’t stop working before achieving it. In this way you will be really motivated in concentrating on work. You targets should be realistic, so doable, but not to easy.
   
   
8. Schedule your breaks
   
   
   If you are working in the office you are also taking breaks: going out to the kitchen to drink a coffee, chat with your colleagues etc. At home you also need breaks at work. I would suppose to stand up from the computer during your breaks. But you can use it as an advantage and you can do some house work during this time: bringing down the trash, do the washing up, put the clothes into the washmachine. Since these activities are much different than sitting at your computer it will be good to do them and as an advantage you won’t need to them after work.
   
   
9. Don’t do every day home office
   

   
   Working every day from home can be really depressing on long term, which leads to losing your motivation. My suggestion is to work 2-3 days per week from home, otherwise work from the office, if it is possible. It makes you able to keep networking with people from personal and professional point of view and it is keeping some routine in your life.

How to measure the productivity of a developer?

How to compare the productivity of developers? Is it possible at all? Is the more productive developer also a better developer? How do increase your productivity? These are all topics for this article.

Why does it make sense to measure the productivity?

Let’s start at the beginning. Why would anyone measure the productivity of the developers? I think it all comes from management side. The management needs to have countermeasures. The management needs to know how good, how productive are the developers to decide about salaries and promotions. And of course the goal of the management is to increase productivity, but how could they prove that they are successful in this field without having a clear measurement methodology? One of the definitions of productivity is result per time. But can result be quantified? The sales team needs to quantify the results to be able to set prices for tasks and projects. Can they do it in a trivial way?

I think the answer is for all of these questions. It is not possible to quantify productivity and result. If you are telling the programmer A is more productive than programmer B that is only your personal opinion, but nothing objective. Let’s see why I am thinking like this.

Measurement methods

There are several measurement methods for productivity I read about or I experienced. I’m trying to list them and show one by one why are they not really correct.

1. Lines of codes / day
   
   I think this is the easiest one to prove that it’s totally bullshit. I can implement the same feature in 100 lines, or in 10 line by using the built in functions of the environment. From quality point of view reusing already working and tested features is much better, than reinventing the  wheel, but it can take more time to figure out which functions are to be used. So if I’m choosing the 10 line solution I’m pretty sure that my LoC/day will be less, than by choosing the first solution.
   
2. Number of commits / day
   
   A commit can be small, a commit can be big. A commit can be trivial or can be difficult. Sometimes it takes days to find the root cause of a bug and to fix it I just need to modify one line and push it in one commit after long days of investigation. Other days I’m implementing small and trivial new features, pushing one feature per commit and I can implement 4-5 small features one day. Am I unproductive at bug fixing? I don’t think so...
   
3. Achieved features / day
   
   
   This is also connecting to the previous point. Sometimes to implement a new feature no investigation is needed, can be done fast, sometimes it takes long days to figure out how a new feature can be implemented in the current environment. And a user of the program can not see the difference, sometimes easiest features are the most valuable ones for the users.
   
4. Estimated hours / used hours
   
   It is also a popular strategy that someone (the developer himself, a technical lead or the team together) is doing a time estimation on the task and later on this estimated time is handled as target. So if you are achieving the task faster than the estimated time you are very productive, if it takes longer you are unproductive. What is wrong here? Who is doing the estimations? If the developer himself than he just need to overestimate everything and he will be the most productive programmer of the world. If a technical lead did it or the team together the situation is a bit better, but in a lot of cases, especially if you don’t have deep knowledge about the code base it is not easy at all to make estimations. I often face with issues, which were not counted at all and takes long time to solve them and it also happened multiple times that I expected a task to be really difficult to achieve and I found an easy solution in one hour. In this can it is again not really about productivity, rather about luck.
   
5. Earned money / day
   
   
   This method is mostly used by freelancers. They are just measuring their productivity in earned money / day. Well if you are encounting money as result than it is correct. But what about days when you need to reinstall your working environment or learn something new? You are not earning anything, but you are working hard all day around. Are you an unproductive developer on that days? No I don’t think so. Or what is the difference if you are developing the same feature for an open source project or for a well-paying customer? Does it make any difference in your productivity? No, it doesn’t.

Connection between productivity and quality

Another important point is the connection between productivity and quality. I think that is common that none of them can be quantized. You can not prove about the quality of your work that it is better than the quality of a colleague. Simple there are too many perspectives.

But what I wanted to say here, that it is faster to produce a code with worse quality: don’t think about tests, code maintainability, documentation etc. For sure you will be faster (more productive) on that one task. But later, when it needs to be extended, or a bug is appearing you will losing all your productivity at figuring out the shit what you have written. You need to find a compromise between quality and productivity.

Productivity of team vs. productivity of an individual

Most programmers are working in teams, but does it make sense to measure the productivity of individuals in this case?

Let me make an example: during the last days I was working from home, I finished much most tasks as I could finish in the office. But after two days my colleagues started to call me, because they had technical issues, which were blocking them. So until I was personally mega effective my teammates were blocked, because I was not there to help them. The summarized productivity of the team was bad due to this issue. If I’m supporting the team mates then my personal productivity will be worse and the team productivity will be higher. That’s why I think measuring of productivity on a personal level is really counterproductive. It motivates developers to support their colleagues what is making the whole development slower. I measurement of productivity is needed, please do it on team level!

What are the influencers of productivity?

The productivity depends on thousand of things. I won’t be able to give the whole list, so I’m just mentioning the most important ones: the developer needs to have the right technical knowledge for the tasks, good experience on the piece of code, a good working environment (good hardware, calm environment), unnecessary meetings and communication should be avoided, good mental state is needed and maybe one of the most important point is the motivation. This topic is such complex that I will write a seperate blog post about that.

Summary

As you can see productivity is a really difficult, but also important topic. I would suggest to avoid quantifying productivity and if it is a must to do it, rather do it on team level, than on personal level.

Possible career paths as programmer

During the previous weeks I was writing a lot about the career possibilities of programmers. First in the article “How to choose the right company for you?” I tried to give on overview about the different kind of companies. After that in “Levels of freedom as a programmer” I wrote about the opportunities of independent working as a programmer. This time I would like to summarize the career opportunities as an employee inside a typical company.

If you are working at a company and you are developing yourself and getting better and better sooner or later you will reach a point where you need to choose the direction of your carrier. These career paths are existing at most of the big companies, however it can be that they have a different name. If identified three main career path: team manager, project manager and technical expert. But next to these three I would like to mention about some less other possibly positions as well: these are the quality manager, technical sales colleague and the trainer. I identified these ones as main orientation opportunities. In case of smaller companies it can be that these are not strongly separated. I also tried to give a short description to each of these positions to help you to decide which is the most fitting one for you.

The technical expert

The usual development of a programmer is something like: junior developer, senior developer and what is coming here? Usually this is the point where you need to decide if you would like to keep on programming or rather concentrating on something else. If your decision is next to programming then technical expert can be a good path for you. Technical experts are often overtaking the role of software architect as well. That means they are designing the new software modules and taking the whole development under control from technical point of view: doing code reviews, supporting technical decisions, supporting other colleagues in technical problems. Quiet often technical experts are also going deep in one topic and getting real experts in that field and supporting colleagues in the special field all around the company world-wide.

But you need to know that technical experts are also not coding all day long: they need to attend several meetings, do discussions with others, support the project managers etc. If you would like to stay technically deep in the topic this is the right path for you, but don’t forget: next to great technical skills you will also need good soft skills.

The project manager

About the role of project managers I have already written in article How to understand the managers?. They are responsible for time and cost planning and tracking of the project. They are communicating with all the stakeholders (customer, high management, developer team etc.) and they are creating a lot of documents (mostly plans and reports). They need to attend usually a lot of meetings. The life of a project manager is typically stressful, since you are responsible of a whole project or subproject. You will need really good communication and stress handling skills. The most typical programs you are using for your work will be Excel and PowerPoint. Usually the project manager is not deeply involved into the technical topics, but it is useful if the manager has a rough understanding of the technical aspectives of the project. At the beginning most likely you will be only responsible for a smaller subproject, but later on you can either overtake a project or all projects of a specific customer. In this case you won’t have any direct connection with the developer team anymore.

The team manager

About the role of the team manager I also wrote in article How to understand the managers?. They are responsible for having a technically fit, well-motivated project which can successfully overtake all projects. For that a team manager needs to attend interviews, 1:1 meetings with the team members, need to define a vision and goals for the team and track them, next to that it is also needed to be in connection with the project managers and with the higher level management. What I see here as the biggest challenge is to communicate in a way with all of your team members which is giving the a good motivation and inspiring them for self-development and for a good quality work. For that you will need really good interpersonal skills. Although the team manager is not deeply involved into the development it is also needed to have a high level understanding about what the team is doing. If you are choosing this direction most likely first you will be responsible only the a small part of the team (5-6 persons), later for a whole team (15-30 persons) and later on you have chance to step one level higher and be responsible for a bunch of teams or a whole department.

If you think you can resolve all conflicts between people it is the right choice for you.

The technical sales colleague

The sales of a software company is responsible for extending the business of the company. To find new opportunities and new projects. Furthermore to figure out the correct price for the projects to be done. For that kind of activity they will need some technical support who can identify the technical strength of the company, who can understand the technical content of project opportunities and propose further features and who can do a good high level estimation of needed development time and needed skills for the projects. These are usually the tasks of a technical sales colleague. If you have more interest in business, but you still want to use your technical knowledge this is also an opportunity for you, however this as a career path is not highlighted at most of the companies.

The quality manager

The quality manager is someone who is responsible for the quality of the products. To be able to do that the quality engineer needs to support the optimization of the development process and take care about that that all developers team are following the process, especially its quality related parts (reviews, documentation and testing). To be able to do that the quality manager is in connection with different development teams usually through the project manager and regularly control the project documents. For this position you need to be precise and quality oriented enough.

The trainer

Most of the big companies have their training sessions for the employees. They are either done internally by colleagues of the company or by an external company. In both cases these trainings are held by professional trainers. The topic of the trainings can be either technical or soft skill oriented (communication, time management, stress handling etc.). This is also an opportunity to orient yourself into this direction and become a professional trainer. It is not taking 100% of your time in every cases, so you can do it next some other activities (like next to being a technical expert).