Building and maintaining a successful software development team 

Just like on a construction site, where the work tempo and quality depend on the builders, so too with software development – you won’t perform well without an effective team, but what do I mean by an effective team? Firstly, its composition – the skills and experience of its members, and secondly, their level of motivation and engagement. 

Apart from all the theory with which we will start, in the latter part of the text I will share with you some practical tips, based on my experience, that boost a teams’ productivity, especially in terms of cooperation between a company looking to increase its development capacity and the software house that is helping it. 

Team composition or, in other words, the right people for the job 

Some of you may think that the best possible scenario is to have an unlimited budget and hire only software architects with decades of experience. That’s not only impossible (the part about the unlimited budget of course), but also would not be as effective as might be expected. 

Willingness to learn 

One of the most important, yet often overlooked elements, is a willingness to learn. No matter if you look for a software engineer, QA engineer, PM, or PO, the world of IT is constantly changing. I believe it isn’t an overstatement to say that while I have been working on this article, at least a few new JavaScript frameworks have been created. While your team members clearly have to know the so-called “core” of their specialties, they should be willing to constantly broaden their knowledge and look for new tools that enable solving project challenges more easily. What’s more, it is not only at the start of the project when you select the tech stack your team will use.  

Nowadays, most projects are long-term, since after the first release, they are not only maintained, but also developed further. So along with product/service growth, new skills might be required. Moreover, constantly evolving technological possibilities are reimagining how jobs are being done, making what once was time-consuming work an easy task, if you can use a suitable tool. Therefore, over time, the skills and knowledge of your employees should expand as well, to ensure that they won’t end up using outdated solutions simply because “some time ago it was more than fine”. 

Technological flexibility 

This subject is closely connected to the previous one, as in my experience those who are willing to continually learn are also the most flexible when it comes to choosing technology for a particular task. What I have in mind, in general, is that you should choose the best technology for the problem at hand, which should also ensure ease of maintenance, not the easiest to use for developers 

Therefore, as I’ve stated before, the longer you work on your product/service, the more technologies you will use. A good example here may be the usage of Python for AI because there are way more dedicated libraries for that than, for example, .NET. You can also embed Python into your projects to eliminate “cold starts” in a serverless environment. 

Years of experience are not a silver bullet 

Let’s look at the example from the beginning and analyze why it’s best to hire people with different experiences and mix senior architects with junior engineers for the most beneficial results. This matter is best to look at from two angles – competency chaos and differences in approach to development. 

Let’s start with competency chaos. As an old proverb says, “too many cooks spoil the broth” and respectively – too many software architects spoil the software. If your team consists of only extremely experienced developers, who all have already worked as architects, this may lead to internal conflicts rather than effective brainstorming, as they all might try to do things their way. We all have some personal preferences on how to do things, and it is the same with the approach to development. 

Too many strong-willed developers working on one project is a sure way to never-ending discussions, but at the same time, everyone involved should have a chance to share their point of view and have it considered. We know from experience that if the ways of working/coding/solving a problem are forced on developers, and their ideas always end up in a drawer, the only result you’re guaranteed is developers’ burnout. The answer? Some level of hierarchy must be present, so that once decisions are made, the team won’t lose their motivation if the final decisions were based on someone else opinions. We can refer to the city building metaphor and compare it to software development once again. On a construction site, you will find a small number of architects and a few construction leaders managing separate parts of the work, with the majority of workers being the builders who might influence how things are done and whose focus is on delivering the essential work. Every group has a different scope of responsibility and skills which allows them to perform different tasks, deal with all obstacles and raise a building that fits all of the client’s requirements as efficiently as possible. We could go one step further and try to guess what the building would look like if the architects and managers were the only ones to work on it – we’ll leave that to your imagination. 

Additionally, when dividing tasks among team members, you should always remember to assign them according to required skills, without falling into the trap of over/under engineering. If you ask an extremely experienced senior engineer to create a simple CRUD, he/she might overcomplicate the solution, which as result would cost you more than it should. On the other hand, leaving junior developers completely on their own with a complex task might result in the creation of tech debt, rather than being a chance to learn something new, and eventually generate costs that could have been avoided. Thus, during the previously described Event Storming, one should analyze the complexity of particular tasks and benefit from having a mixed team through choosing the right people for the right tasks and benefit from having a mixed team through choosing the right people for the right tasks. 

But as I said, there’s more to it. After years of working, we all create “our own footprint” – our ways of approaching tasks and dealing with challenges. The more we do, the more these practices became ingrained, and eventually, we might even lose sight of more innovative solutions. Therefore, mixing senior and junior engineers in one team is a great way to get the best of both worlds – on one hand, you have the extensive experience and extremely broad knowledge of seniors, while on the other a fresh, unbiased view of the work from younger specialists. This combination is incredibly effective and, in my experience, a crucial factor in successfully delivered projects. 

What’s more, experience clearly indicates that many senior engineers enjoy sharing knowledge and mentoring their less experienced colleagues, which benefits everyone involved – juniors have a chance to grow, seniors feel satisfied with a mentoring role, and you get more qualified and engaged employees.  

Motivation is more than a buzzword 

Once you have managed to find the perfect people to execute your idea, it is time for the almost equally difficult task of keeping them motivated. This is notably important for two reasons – first, as we all know, motivated people work more effectively, motivation improves creative thinking and allows us all to get done as much as possible during the proverbial 9-5. But that is not all. 

Nowadays, there are far fewer software developers than development projects, so the best talents can find (if headhunters won’t find them first) a new job within a few days. Therefore, if they get bored in your project, their ideas are ignored or the atmosphere is poor, they will most likely decide to leave immediately. As a result, taking care of the environment in which your developers’ work should be treated as an investment, not a cost. So, what should you pay attention to? 

Integration 

While integration activities for internal employees are already standards, let’s focus on a situation in which you have decided to work with an external partner. It’s not only a scenario I’m extensively familiar with, but also, it’s an extremely effective way to boost your development capacity, or simply build your development department from scratch. In such a scenario, the integration between the specialists hired and provided by a vendor and a client’s internal teams has a strong impact on productivity. On this blog, we have repeatedly touched on the topic of intertwining business and development – whether at the stage of planning, selecting and creating DevOps infrastructure or as part of quality assurance.  

To be effective, an external team needs to feel like part of your organization, understand how it works, and „not be afraid” to throw in their ideas for solving problems, while your internal employees should treat them like co-workers, not contractors. The more comfortable the developers feel, the more value they can deliver – it’s a fair point to say that the code is just a part of software development outsourcing value. 

Share domain knowledge 

Let’s stay with the example of cooperation with an external partner, because again, while onboarding and sharing domain knowledge in the case of internal employees is a market standard, the same is often overlooked when working with an external software supplier. As we often mention, at the stage of selecting a supplier it is worth focusing on companies that already have some experience in the area in which you operate, which will allow them to start working at full speed faster. However, no two companies, projects and problems are identical. 

That’s why it’s extremely important, when working together, not just to provide the external team with user stories to code, but to show them the whole picture – explain what they’re doing and why it’s important, what problems they are supposed to solve and how their work will make money. This will both boost their engagement and generate a sense of responsibility (because they will not feel like workers but co-creators) while also increasing the chances that they will be able to help you solve potential problems or locate areas for improvement that you or your internal specialists might not have thought of. After all, two (or twenty-two in the case of big teams) heads are better than one. 

Don’t fear conflicts, solve them 

Conflicts are part of the process. Especially with long, complex projects, minor conflicts within a team are inevitable, but it’s not the conflicts that can put your project at risk, but a failure to respond to them. In my experience, the sooner problematic situations are addressed, the easier they are to solve and the less they affect team members’ motivation to work. We spend a significant part of our lives at work, and we want to spend it in the best possible way, in a good atmosphere, using and developing our strengths, so sweeping conflicts under the rug can only lead to problems piling up. Thus you, or the assigned manager, should always keep a finger on the ‘team vibe pulse’, and if it’s starting to drift into dangerous areas, take action and guide it back to a safe shore. 

Good tips for having building a terrific close-knit team 

Organize onsite visits 

Nowadays, it is straightforward and effective to cooperate and work on software development remotely – I think, especially after 2020, no one has even the slightest doubt about that. However, even in such an arrangement, the possibility to get to know each other in „real life”, to exchange knowledge and shake hands or casually discuss non-work-related topics is a very important element of cooperation, both in the case of remote in-house teams and cooperation with an external development provider. Therefore, while you can reap all the benefits of having teams in different locations, often in different time zones, and work using asynchronous communication, organizing face-to-face integrations from time to time will improve the effectiveness of individuals’ daily work and the cooperation between all people involved. Such integration can be both a meetup arranged strictly for fun, for the sole purpose of establishing closer relations between team members, or it may combine work with additional activities „after hours”. Even a few days during which developers can sit in one room, work „desk-to-desk”, drink coffee in the office kitchen and grab a beer together after coding, will make it much easier for them to get along and work together effectively. 

I once led a project for a client in Germany, which in the initial phases, did not go smoothly. Although we managed to achieve the desired objectives, I could not describe this stage of cooperation as „seamless” because of communication problems between Software Mind developers and our client’s in-house developers. To solve this problem, we organized a 3-day integration, during which they visited our office, we had the opportunity to work together in one place and spend some quality time together after hours. This short period was enough for both sides to start perceiving and treating the other side differently. From this point on, all the discussions related to the development, or system architecture, did not pose a risk of conflict. Instead, they produced additional value resulting from the combination of many different points of view and experiences of all the participants who started to understand that those who disagree simply want to achieve common goals, rather than getting things their way. 

Keep in mind cultural differences 

There is a lot of information online about cultural differences and their influence on cooperation, but it is so important that I cannot leave it out of my list of „good tips”. First of all, of course, the smaller the cultural differences between you and your vendor country there are, the easier it will be to understand each other and work together effectively (read this blog entry if you want to find out what characterizes Polish software developers). However, what I would like to point out as my „good tip” is to pay attention to details that can make or break the cooperation, and which are often overlooked. An example of such detail that first comes to mind is the word „problem”. We Poles usually understand it as a challenge, an obstacle we have to face, while for our US-based partners „problem” is immediately associated with doing something wrong or damaging something, which often became a reason for confusion. 

Another example can be the understanding of a deadline – in this case, while everyone understands what this word means, the approach to this term may differ. We treat it as a date by which the tasks have to be completed and handed in, whereas I remember that Germans always tried to hand in tasks well before the deadline, while the French approached it with more flexibility – but I won’t elaborate more on this here, since that is something, we already cover in the aforementioned blog. In conclusion, keep in mind cultural differences, as they will allow you to understand the intentions of the other side, since even in the case of geographically and culturally close countries, some differences always exist and ignoring them has never helped anyone. 

Make friends 

It may sound like a tired cliche, but it’s not. We spend around 8 hours a day at work, that’s 1/3 of our day, so a friendly atmosphere and good relations with co-workers influence not only our comfort, but also impact our motivation and engagement. Moreover, especially when working with people from different countries, it is also a great opportunity to learn about new cultures or different points of view of the world. I remember when I was in primary school our teacher would encourage us to write letters to our peers in the UK or the US to improve our language skills and get to know people from different cultures. Now technology allows us to talk in real-time with people on the other side of the globe and we can use this for more than just doing our jobs. 

Different cultures, behaviors, experiences – getting to know all these things allows us to grow, and openness positively influences the process of building relationships between team members. Friendly relations definitely improve everyday work, and when things go south and a deadline is approaching, it is the relationships that allow team members to pull together and deal with even the biggest difficulties. So how one can start building them? Apart from the aforementioned integration events, my experience shows that every country has a sporting pride, a team or an athlete who is on top, and even people who are not big sports fans know something about this, making it a great starting point.  

For example, if a country is good at volleyball, find out who they last played a match against and ask about it, maybe your countries even competed in a tournament against each other. This is, of course, one possible starting point, which in my experience worked well, however, it is important to remember that going beyond purely business relations will allow you to not only get along better during project work but will also show you different perspectives in the world and broaden your horizons, allowing you to get something more from work than just a salary, a set of company benefits and new professional skills. 

Learn some foreign words  

Currently English is the main IT language across the world and most of the communication is exchanged in it. If that’s your and your partners’ native language, then you can skip this paragraph. If not, I highly encourage you to learn some foreign words in the language that’s native to your external team. It is very pleasant to hear “please” or “thank you” in your native language during a project meeting with your client. It’s also entertaining to hear someone twisting his/her tongue to try to say something in, for example, Polish – long story short, it might not be as easy as you may think, and helps all people involved to bond.  

Since I promised real live examples, I currently lead a project for a US-based client, who starts each meeting with “Cześć, jak się macie?” which stands for “Hi, how are you” in Polish. While her pronunciation is far from perfect, this instantly makes all of us smile, improves the atmosphere and increases engagement during even the most challenging parts of the project. 

Grab a beer 

I think that this one doesn’t need any clarification. Just go and grab a beer with your teammates. If you plan an onsite visit, that’s an ideal opportunity, yet even an online meeting will do. Casual conversation, accompanied with a beer (or any kind of beverage, just leave work out of the equation for this one meeting) is a perfect ice breaker for any dispersed team. I guarantee that such a session will make the atmosphere better, encourage team bonding and positively affect all the subsequent work. What’s important is that while sitting together in a pub people usually start to chat instantly and while transferring this experience online may be demanding, it’s more than possible. During the pandemic, we had a chance to organize both internal and external integration sessions. While at first playing online games and saying „cheers” to our monitors seemed like a cheap substitute, we had so much fun with online charades and other games that I’m positive distance is no longer an issue. 

Software partners who know how to build software development teams can make all the difference. Use this contact form to get in touch with our experts – our specialists are waiting to hear how they can help you achieve your business goals.