I joined Teleopt in 2012 and this article is my experience of working here. Of course, it may vary in different companies, with different processes and different people.
A healthy team
While working in Teleopt I have been working in different teams and different locations. The diversity of RnD in Teleopti expands from different physical offices to multiple development cultures within the team. During my time here at Teleopti, I have been in teams that have their own working process and practices which made them more effective and operational.
When I started working at Teleopti, I was part of a team which was located at two different locations so occasionally I had to travel to the other office. Once we were at the same location we normally pair-program or discuss the upcoming tasks to have a consensus on what needs to be done and divide the tasks among the team. That is if we don’t want to pair and perform the tasks together.
After that, I joined another team where we were working on setting up infrastructure for some major change in the product. of course, that involved a lot of discussions and prototypes so working closely and more frequently helped us to achieve our tasks. The team was still at two different locations.
The third team that I joined was in the same location and was heavily doing mob programming and pair programming. We were more or less following the standard rules for mob/pair to work together. of course, that also involved discussions but while pairing and mobbing we had a consensus on how to move forward.
So among all those jumps what I have learned is
Closeness is the key for a happy team, regardless of whatever the team rules or process are the closer and more tangled you are the more you are in control of the situation. Even with the hardest conflicts and discussions we always prevailed. I will talk more about communication later to discuss how to act and tackle situations when you are communicating with different people.
Don’t just agree, understand it, when you are in teams you will get into a lot of situations where you have to discuss the problem statement and all aspects of the solutions. Sometimes there is a certain team member who has been working for quite a while with the company so their way of seeing the problem could be more precise. Even though some are good at finding the solution but they probably will ignore the fact that you might not be familiar with all the business and domain and may give an aerial view of the solution. In those cases, don’t just agree to the solution if it is handed to you. A detailed autopsy is more enlightening to the potential of understanding the solution.
Engage your manager Sometimes it is a bit selfish to think that your manager knows everything. Yes, you might have your one-to-one throughout the year but expecting a reward or recognition for something that you did and told your manager a few months ago is not practical. Your manager is managing other people, performing administration work, and busy in other ‘manager related’ tasks. The best way is to fog your work in a continuous cloud around the manager (and not be irritating about it) is to keep on reminding you about your success. Be the potential selection of the next opportunity by being prepared for those upcoming assignments. If you keep on reminding your manager that you are experimenting with things that are related to the existing or upcoming assignments you will be the first natural choice for any task related to that.
Pair-mob program, I think this is the best approach to problem-solving situations. The continuous code review via test-driven ensures that the code is bug-free and has improved quality. But how does this impact a good and healthy working team? As you know that good and quality code ensures a stable product. A proper and thorough quality assurance will give a better tested and stable solution. This in return profits good user feedback which serves as positive energy for the team. This heavily depends on the teams. A single person can achieve the same impact while working alone as well. Even when we are following the flexible process within the team the overall development process should be respected. The processes ensure the success of the team which is developed based on the chemistry of the people involved within the team.
Be patinate, not fast, we should take pride in what we make. Always be patinate about your work don’t haste to conclusions or solutions. Take an example of the food industry if I want to order a burger it will be made and delivered to me in a minute. of course, they can be innovative in how they put up the ingredients but their main aim is to get the job done. Unfortunately, the software industry doesn’t share the same work norms as the food industry. In software development, you can be as patinate as you want but don’t overthink it either. The more you are patinate about your work the more you will enjoy it. This necessarily doesn’t mean that you will have the best days. There will be days that will be harder than others than don’t challenge or blame your knowledge. Instead, evolve in techniques to how to handle those situations and the ability to overcome
Communication
As a developer we have to communicate on any level, we need to have a discussion with the product team to know the requirement or the feature we want to develop. We also need to discuss prototypes (if required) with stakeholders from different departments to get feedback. We have to talk within the team to find and explore different and optimal options to implement the solution.
We also need to have a discussion with the customer to get feedback. So in our routine, we will encounter the most difficult social challenge and that is communication.
Know what to say, plan your conversation before having it. If it’s verbal communication with a client or stakeholders write all the points down that you want to discuss. Run through them at least once so that you remember the history and context behind the text that you have written. In email and written communication, go through all the text at least once. Some people like to the point and direct communication while other people like it through and detailed. You have to find the balance between that. Always visualize the possible answers to anticipated questions in your mind before having the conversation.
Be active in expressing yourself, This goes for communication that is within and outside the team. At Teleopti we used different types of communication channels at different times including skype, skype for business, and Teams. These different mediums are good automation tools for digital workplaces but the essence is always physical communication. At Teleopti we have a concept of ‘One Teleopti’ where we act as one team regardless of which department you are in or which skill set you to have. The key to achieving that is communication. You can always use the digital workspace but if you are located in the same location it’s always good to go to the person physically and talk face to face. This will initiate a discussion that also involves your emotional input which is hard to achieve over email and skype conversations.
Choose a moment, we all are communicating with everyone on a different level. Sometimes when we get stuck in a problem or have a quick question from someone we either send a mail or ask directly. It is always good to analyze the time when you are engaging that person in a conversation. Is he/she going home, is he stressed out about some customer or a release. Is there a lot on his plate? All of these factors matter. There are important things that they need to hear but you should also be aware of what their priorities are at that moment.
Be a good listener, if you want your communication to be successful then be a good listener. The one thing that I learned while working at Teleopti is that when I talked to a senior developer they always listen very carefully to the argument even if they had more information than me. This gives the confidence to ask questions, courage to think more in-depth. It also gives importance to each member of the team. Most of our meetings are not just meeting they are dialogs. The meeting is derived in a way to encourage people to ask more and more questions. This will give them time to think about a problem and the team will feel more equal when it comes to quality in the team.
knowledge portfolio
As a developer, we always need to update ourselves with the latest technology along with the evolution and improvements in the existing systems. The improvements could not only be in the technology but it could also be in the domain as well where one team might have done something that is worth sharing with others teams and it might be important for others to know about it. 
At Teleopti personal growth is one of the building blocks of a strong team. Every now and then we have explorations days where we team up with people outside our conventional teams to explore new technology, new area, possible extension in products,s or whatever we wanted to do in technology. It not only gave us the opportunity to learn new technologies but also give us the chance to work with the other teams. It’s an opening to get to know them more and also to learn what they know.
So with all these things in mind you should
Expand your skill level, you should be able to expand your skills. Learn new programming languages at the conceptual level so that you diverse skills in different areas. We at Teleopti are working in different areas so we keep on exploring different parts of the system. We work in Angular, test-driven development, Azure technologies, and .net technologies. With so many diversities of the existing technologies, we keep on learning and improving technologies around us. There are two main benefits of such learning techniques. One is that you will be equipped with more technical skills. The second benefit is that your team will have more knowledge as you as a member will contribute more. But individually it benefits even you as you will be the next logical choice if that skill is required within the team or the department.
Read books both technical and design level, With today’s age of the internet you don’t have to read a book to keep yourself updated but it’s always a good practice to read one. There are many books on the design and architecture level that gives good insight into the industry standards plus the experiences of other people. That doesn’t mean that you have to read a technology-related book. There are books that are nontechnical as well which are good to read.
Try out different environments, At Teleopti we are mostly working with Microsoft technologies. Different developer in different teams is using their favorite IDEs. Most of the developers are using visual studio but some developers are using Rider, Visual studio code, or sublime. With this diversity and liberty, the developers get to experiment with different IDE. This is a good practice because once you are familiar with more than one working environment working in pair and test-driven is much easier.
Read articles, normally I use Twitter to keep myself updated with the latest news and updates in the market. But you can use any resource on the internet through which you will get the latest news about the area in which you are interested. Keep yourself interested in the programming language you are working in, read about updates in framework and SDK, new versions of the language, etc. If you are a developer read more about the architectural resources to equip yourself to think outside the box. If you are an Architect then read more about the framework and SDK updates to know the technical limitation and extensions that could be useful for your domain and solution.
Catalyst to drive
While working within a team it’s important you contribute equal efforts in the teams. You are one of the stakeholders of the task at hand so it’s critical that your thoughts are contributed are expressed. But sometimes is hard to communicate with the other team members because after all we are all humans and we can’t ignore the behavioral factor of every team member which will be quite different from each other.
For a team in which most of the team members are equal in teams of domain skills and a number of years working in the company, it may not be a problem. But it won’t be like that always. You will have new hires, a few people who have spent a year or two, and some that are with the team since the beginning.
These dynamics dictate a special set of skills to adjust and function.
Make the stone soup, a group of soldiers came back from war and they were on their way home. They were tired and hungry after the long war and tiring journey. For days they were walking and had no decent meal. They came by a village on their way home and thought they will be greeted and well-fed. But when they entered the village they were really surprised as no one greeted them. Despite their call for food no one answered because the people themselves had not enough to eat. The soldiers thought of an idea. They poured water into a big pot and added three stones to it and put it on fire. They sat around it and started talking about the magic stones they discovered that they were using in making a soup. The villagers started to notice them and they came out one by one and also started to talk about the stones and the soup.
One of the soldiers said if there were some carrots that would add some taste to the soup, a villager stood up and said he has some carrots. He went back to his home and came back with a basket of carrots. Then the soldiers said it would be really great if they could add some potatoes to the soup. Another villager stood and said he has some potatoes so went to his home returned with some potatoes. Eventually, the villagers contributed to making the soup that was enough for all of them. In the end, the soldiers removed the stones and they all enjoyed the soup.
In this story, the soldiers acted as a catalyst to change. Their act derived the villagers to open up and contribute to the joint effort. In our daily life, we could also be a driver to perform the change. If you notice a code that needed to be refactored or see any improvement in the system make a prototype of the area and present it to the team along with the limitations that you are facing. Once you make these changes people will see an opportunity and will contribute to work with you with their own skills. This is the organic way of making a productive team. For the villagers, the soldiers added a deceptive motivation which proved right and they all were rewarded in the end.
Take responsibility, you should take responsibility for the code you wrote. Don’t do the blame game instead accept the fault with grace. These things are not pointing to something personal but they are an improvement to your professional life. The fact that some people cannot take the critics positively doesn’t mean that they write bad code but they lack the ability to educate themselves and to evolve to be more professional.
Don’t blame framework or vendors for the problems. Don’t come up with excuses rather come up with options and workarounds. Think of contingency plans for proactive support. If your product is already live saying that ‘it won’t work’ will neither help you nor the customer. Think of hard fixes and workaround that could help the customers. If you find any problem or security risk in the product highlight it as soon as possible. Let the right people know about it so that appropriate actions should be taken.
In the end, be open and flexible in your work. Be involved in the uncharted territories of the application, which will give you more confidence and experience in the domain and the product. The biggest problem for a team should be when their most passionate and motivated employees become quiet. So express yourself more and be the building block of a happy resource and productive team.
Some of the recent achievements of Teleopti being such a successful company us that it’s now being acquired by Calabrio.