Software development is a team sport
Ask yourself the keys to good software development and you might think about user experience, performance or security. But what about the people? Strong software is built on even stronger teams, and good relationships are the foundation.
So, what exactly constitutes a good relationship with your development team? It starts with transparency; being open and honest about issues such as:
Future costs – how these will impact the project and scope long-term
Maintenance needs – helping to forecast workloads to avoid nasty surprises
End of life problems – understanding when code may need rewriting
Honesty leads to long-term relationships, which helps with continuity planning and promotes sustainable code. Rather than incentivising developers to get the job done quickly and move on, we should think about the long term. In doing so, we avoid the dreaded ‘towers of knowledge’.
Avoiding towers of knowledge
We’ve all heard stories of one key person leaving the business and taking the knowledge with them. In a software development context, this is when one single employee knows about a critical part of the codebase – whereas others are in the dark.
This presents a risk to your business if said tower of knowledge leaves. Internal knowledge management discourages working alone, instead giving developers the opportunity to receive continuous design feedback.
The benefits here are two-fold. The developer wastes less time making mistakes, while peers can offer thoughtful code reviews. As managers, we should dissuade developers from making undocumented shortcuts. Instead, a knowledge-sharing approach promotes more collaborative work methods.
Balancing costs and in-house development resource
So, how can we share knowledge if there’s nobody to collaborate with? The logical step would be to hire more developers, but this comes at a cost. It’s important to consider what impacts team size, for example:
Complex applications – these may need a diverse team of specialists
Project phases – testing may need fewer team members than design, for example
Large codebases – these require more efficient code and bigger teams with more knowledge
Locations – geographical factors like time zones may need larger teams to coordinate projects
When we think about costs, we can also consider in-house versus outsourced development teams.
In-house vs. outsourced
If you’re not a developer by trade, you might struggle to make the right hires in-house. Your first hire does more than develop software – they’re also the Chief Technical Officer, making key tech decisions for the business.
This is helpful but also risky, particularly if they hold the keys to your code. The best in-house teams function in pairs at a minimum – helping with handovers for continuity.
But what if this goes beyond your budget? Outsourced development is a cost-effective alternative, whether it’s a freelancer or an agency.
Hiring a freelancer: pros and cons
Freelancers can often start projects quickly, helping you avoid red tape and awkward tendering processes. Some may be full-time freelancers, whereas others may be filling in professional gaps. This can bring a diverse range of skills and opinions to the table.
Be mindful, however, that said freelancers’ schedules may fill up quickly. They may not always be available for updates or maintenance. Like single developers, it’s essential not to put all your eggs in one basket.
Outsourcing to an agency: pros and cons
Agencies are ideal for handling staff continuity and training, alleviating the worries of relying on a single developer. They may have experience in your industry and more concrete contractual terms, giving you assurance on issues such as maintenance.
Of course, this comes at a cost – often more so than freelancers, but also less than full-time staff. Once again, it’s key to avoid towers of knowledge, particularly if you part ways. Always ensure you ask your agency what their plans are for internal knowledge transfer.
Remember: long-term planning is key
Whichever model you choose, be it in-house or outsourced, you need to think about the long term. Don’t fall into the trap of relying on short-term contracts for the most competitive price. This may discourage your current partners from investing in innovation. After all, there is no guarantee of future business.
Continuity planning
We never know what’s around the corner. At some point, you may switch from in-house to outsourced, vice versa, or even a blended model. Making an effective switch comes down to continuity planning.
As a business owner, it’s your responsibility to ask developers about continuity plans to hand over knowledge. This avoids disruption and encourages knowledge sharing among others – even more important if you are switching. Take the pain out of it with this three-step process:
Before the switch: make sure all your software documentation is up to date and comprehensive. Include technical details, usage guides, troubleshooting resources and training materials.
Plan handover resource: empower the outgoing team to brief the incoming team on the intricacies of software, codebases, systems and procedures.
Assign clear roles: give both the outgoing and incoming team roles to prevent gaps in knowledge, and cover every aspect of the software.
Ideally, you should also have a back-up plan, such as temporary contractors or support from the outgoing team. Ensure you maintain regular and open communication between all parties. This will help to manage expectations, address concerns and keep an eye on progress.
The takeaways
The key to building better software is effective development team management. Whether it’s in-house, freelance or an agency, transparency takes centre stage. We need to apply strong communication and planning techniques to assure business continuity, as well as foster sustainable development.
There is plenty more which could be said on how teamwork and communication impacts on software development. However if you focus on relationships and you’ll work through these problems together – collaboration is the first step towards productivity.
