Outsourcing your software development? Do these 6 things first
It was the Friday morning all-hands call. There had been three incidents earlier in the week, and the CEO of the startup looked exhausted. He threw his hands up in the air.
"Why is it," he asked, "that in every new version of the app, something breaks?"
I could feel his pain. I knew the reason why most of those problems were happening. They made the same mistake that so many non-technical founders make when outsourcing development work.
The team was putting in the time and effort but the results were still lacking.
On one side, the developers had been working long hours, putting out fire after fire for many months now with no time to plan, only to react. They never pushed back when they had to and were far too used to archaic methods of software development.
On the other side, the business was pushing the development team beyond what was wise, not realizing that the Jenga tower was starting to wobble.
A couple of weeks before, when I recommended changing the way the team worked by slowly introducing software development best practices, one of the startup’s technical advisor told me:
"We don't have the time and resources to work that way. We are a startup and have to do many things the ‘quick and dirty’ way."
I just thought to myself:
“You’ve been doing quick and dirty for over a year and now it has come back to haunt you”.
If you are planning on outsourcing the development of your application, start with these 6 things to avoid making the same mistakes this startup made.
1. Be Specific About What Product or Service you Want to Create
When looking for a development team, 15-30 minute calls are not enough for a technical person to understand your product and come up with accurate time and cost estimates for its development.
You want to paint as much of the whole picture as possible, even though you know the picture will change over time.
"Taureau" by Pablo Picasso
Prepare and share a requirements document with the potential development teams. This will take you a few hours or even days to complete, but it will save you in the long run.
Your document should include:
Context and description of the product and problem to solve.
Scope: what is part and what is not part of your product?
Mockups or drawings of how the application should look like.
How are users going to use the application and what are the possible use cases.
Dependencies: internal systems, people within your company or external companies.
Short long term goals for your product.
Assumptions.
This changes the dynamic in the conversations. Their discovery questions will be more specific instead of trying to gather complex requirements in a short call. You will also be prepared to answer their questions in a more elaborate way.
2. Choosing a Partner
Ensure the team you hire has the skills and experience that you need to deliver your vision, both non-technical and technical.
For the non-technical skills, evaluate if the company aligns with your values, understands your vision, can communicate properly, and is proactive. Can you see yourself working closely with them?
In the startup example, the team was in a different time zone, most of the team didn’t speak English and the people that did were filtering too much information to the rest of the team. There was an abysmal disconnect between the business and the core development team.
The required technical skills will vary depending on the complexity and scope of your product, timelines and budget.
If you choose the right technologies and work with experienced people, you will reduce the development time, complexity and will build a robust product that can scale in the future.
Some discovery questions you can ask are:
How do you manage your projects and demonstrate progress?
What technologies have you used to develop similar projects?
What are the usual roles in your team and their experience level?
What does your testing process look like?
Are the developers part of the current team or do you need to do some hiring?
3. Speaking the “Same” Language
What technical people say or understand can be completely different from what you are saying and vice versa.
I once told a man what I do. I thought I was using casual language and only a few technical terms to reference some technologies that I use: “big data”, “natural language processing”, “cloud technologies”.
He was baffled! He told me that he didn’t know the meaning of at least 5 words I mentioned. Crazy right?
During the development process, ask for clarification or examples if you don’t understand the terminology.
Make sure you and the team are on the same page.
4. Be Specific: Leave no room for assumptions
I once found a task with a description that said:
“The video and voice calling screens should look like the industry standard”.
What would you create if you were the person working on this task? So many options to choose from! WhatsApp style? Or maybe a combination of the most popular calling apps?
You have to be more clear than that. The calling functionality was the core feature of this product. A crucial decision like this cannot be left to a busy and overworked developer.
This brings me to the next point.
5. You are the Director of the Orchestra
Requirements are great and necessary but they are not enough.
You have to be actively involved in the project and create spaces where the development team can have easy access to you and ask questions.
You need to make decisions along with the team and ensure that what is being created aligns with what the business needs.
Be part of the team demos to see the progress.
Ask and let them ask you "silly" questions.
Have regular and short meetings with the team.
6. Minimize Risks and Remove Uncertainties.
Have you discovered and assessed the technical risks of your product? How does it affect your business plan?
When you understand the software development process, the best practices and your role in it, you’ll have a greater ability to create and respond to change.
How does this look? For example, daily short meetings, incremental development cycles. Refinement and planning sessions to clarify tasks and decide the work that brings more value in the next weeks. Version control, quality assurance processes and some automation to reduce manual errors.
The Happy Ending
The startup I mentioned before tried making things work with the original development team with no luck. They hired a new development team after an extensive company evaluation process.
The new team has vast experience creating applications, has strong technical skills, culture and collaboration environment and uses the software development best practices.
Business and development teams are aligned. They understand the short and long term goals of the startup and this is guiding the application design.
Oh, and they are creating a new application from zero because fixing the mistakes that were made using the quick and dirty approach were too costly. In the long term, it is going to be faster, cheaper, and easier to scale because more forward planning is being used.
