We live in a time when there are numerous options for outsourcing your development work. Post on LinkedIn about a coding job that you need to do, and you will get 10's to 100's of responses. But how do you pick an outsourced development team?

Since 2015, Carnedd director Edward Aslin has worked as a technical lead, a fair chunk of this time as a consultant. As such, he has worked in quite a few development teams. During this time, he has seen the running of development teams done well and badly.

How a development team is run directly translates to the quality of the code produced, and in turn affects your return on investment.

If you are considering hiring an outsourced development team to work on a project for you, The below list, while not exhaustive. Is a set of questions that you can ask. The answers to this can help you distinguish teams with a higher likelihood of producing good code, and a successful project.

Question 1: How do you motivate your staff

If your development team is not properly motivated, your project is doomed from the start. So finding out how a company motivates its dev team is important. Due to the fact skilled developers are in demand, you would typically expect bigger motivators than you would see in other sectors.

It used to be you could motivate a development team by offering them free snacks and a football table; it does not work like that anymore. The bar has been raised. The 2020 Stack Overflow Developer Survey suggests that you motivate developers by giving them good work-life balance, flexible working, strong culture, and remunerating them well.

Make sure the company you are outsourcing motivates their staff, with methods that are in line with what developers actually want.

Question 2: Do your staff work overtime

Staff who work overtime make mistakes. There is only so long any individual can stare at a screen and do what is effectively a complicated puzzle. Proper rest and downtime are required, to get the best code out of people.

Staff who work unpaid overtime not only make mistakes but resent their employees. Neither of these things makes for happy contributors to code bases. Look for an agency that has not built its business around expecting staff to work for free, and realizes the value of well-rested, happy developers.

Question 3: What is your staff retention rate like?

Linked closely to the first two questions. Poor retention rate is also an indicator that things are not quite as they should be in the team elsewhere.

In a typical dev team, switching developers on projects can be disruptive and time-consuming. It will eat into the hours you are paying for, and it will result in technical debt, directly affecting the quality of the product produced.

Question 4: Do you use Git?

Git is a form of version control. Used properly, it is like a time machine for your code, and it facilitates multiple developers working together on a project simultaneously. Version control, such as Git, is a cornerstone in all good development practices.

If a development team is not using Git, you can guarantee there is a very little workflow or process elsewhere in the team, projects will take longer, and be prone to software development issues that were resolved for most people in 2005...by correct implementation of Git.

Question 5: Are the senior members of staff coders?

The classic response here is

They wrote a little bit of code once

See translation

"No, they can not code".

You want a development manager, to have done their time in the trenches, and to still be actively coding and staying relevant. Writing a bit of code as a hobbyist, or writing some code long ago, does not qualify you to run a team of developers.

If a technical manager cannot code, they cannot review their developer’s code. They cannot tell the difference between a well-built product, and one made of string and bubble gum. They are far less likely to have a profound appreciation for the intricacies and the trade-offs, that have to be made every day. As a result, they are less likely to oversee the build of a quality project and deliver it on time and within budget.

Question 6: Can you provide an example of a client for whom you built, and maintained a codebase for over a number of years?

Building a product is one thing, maintaining it, and a relationship with the client over a number of years is a very different thing altogether. You do not want to work with an agency that will build your project, and then "throw it over the wall". Providing minimal support for a short length of time before ghosting you. This is particularly common when a product is not built well in the first place, as it’s very difficult to monetize the maintenance of poor-quality code.

A supplier “ghosting you” comes to wit notable problems. Passing projects between agencies like this is time-consuming and pricey for you. Find an agency that has a track record of building products and long-term relationships with its clients.

Question 7: Tell me about how you foster inclusivity in the workplace?

The best development teams are made up of a diverse mixture of people. Diverse in gender, education, experience, and neurology. But you can only make a development team like this if you are a truly inclusive workplace. Saying

“Everyone is welcome here"

Yet not making the required changes to make the workplace inclusive to all is why a lot of development teams tend to be dominated by university-educated white men.

To accompany the university educated, you want self-taught coders, you want coders that came to coding later in life after doing something else, you want people with different perspectives on life, you want people that think,  look at, and solve problems differently to anybody else.

Question 8: Can you provide examples of how you use automation in your development process?

It is a very "old school" mindset to be averse to automation in the development process. Nowadays, it is the best practice to automate everything. It saves busy work, prevents human errors, and frees developers up for the bigger challenges that they face in the creation, and long-term maintenance of a product. Yet numerous older developers can be reluctant to change.

There is no right or wrong way to do this, as there are many forms of automation. What matters is that the team is embracing it, and not doing all the donkey work manually whilst charging you for it.

Question 9; How do you ensure smooth communication with us, and ensure nothing is lost in translation?

The ability to communicate technical ideas, to the none technical. Is a crucial skill for a successful development project. Ask potential partners how they do this.

When outsourcing to a development team where the language and culture do not match your own can often lead to problems too. Little details are often lost in translation, and these little details can have big consequences on the success of a project. Ask a potential partner to demonstrate how they prevent this from happening.

Also published here.