August 12, 2021
“Have you used a remote team before?”
This question is perhaps the most common and yet effective question you should expect before embarking on your partnered engineering journey. If the answer is NO, then you probably have the same questions and concerns as other managers have had before you. You are not the first person to ask yourself: “How do I start?”, “What makes a good pilot assignment?”, “Who should manage this relationship?”, “How do I prepare?”, and so on. We have written this article to help you answer most of these questions.
The focus of this article will not be on explaining how to choose a good partner or how to negotiate terms. This article is about what type of projects and people you may want to consider in your organization, as a Client, when outsourcing to a new partner for the first time. It will also help you prepare for some of the questions that your new software engineering partner will most likely ask before moving forward with your collaboration.
Since this is the first time you’re engaging with an external partner on an in-house assignment, you might be tempted to start the relationship with a “side-project” or with “that project that nobody wants to do” in your organization. DON’T DO THAT. To maximize your chances for a successful start, you must ensure senior stakeholder buy-in. Choose a meaningful project for your business, one that senior stakeholders care about, monitor, and budget for. Build a roadmap. Set up clear and specific goals that you want to achieve by partnering on that project. Explain what you need to be built and how you plan to do it. The senior management team should support the initiative.
The fear of venturing into the unknown is perhaps one of the biggest challenges when introducing a new work approach to the team. However, simply getting senior stakeholder support may not be enough. Both your executive and technical leadership must agree that an external partner should be engaged; both should commit to helping when needed. Communicate openly with your team and answer any of their questions about the engagement and about what the working relationship might entail. This will help you obtain their buy-in for the initiative much faster.
Very few good things were ever built with skeptical people and nay-sayers. People who don’t believe in a concept or idea will easily find ways to prove you wrong and say, “I told you so”. Of course, that doesn’t mean they are right. But, it also doesn’t mean that you shouldn’t go ahead and do it.
Focus on finding those people in your company who are driven by curiosity and innovation. You don’t necessarily need people who outsourced before, but people who care about the project and know your organization well. They will be better prepared, more likely to collaborate, and will feel professionally accomplished when things will turn out successful.
While these people may not necessarily be your highest managers in command, it is key that they are knowledgeable subject matter experts who believe that an external partnership will work. Or at least willing to give it a chance and invest some energy in building personal rapport with fellow remote engineers. It is wise to ensure that such people are willing to share knowledge, spend time (online meetings), provide guidance, mentorship, and support, and maybe travel abroad occasionally to meet their remote engineering team (e.g., two or three times per year).
Since this is your first time partnering externally, select a project that is not too big, but not too small either. As a first engagement, the ideal project size should be in the range of two to seven outsourced roles. Involving more people in the beginning also increases the risk; having less than two people is disengaging – for you and your external partner. If you only have a single role to fill, in the current market, you’re probably better off hiring a freelancer.
As for the project duration, it should ideally require more than six months to build. When starting a new collaboration with a company in different geography and culture, it takes time to build common processes, personal chemistry, trust. It will take a few sprints before reaching a good development velocity.
At the same time, you may not want to commit to more than one year of work in advance. You should be able to extend as you get closer to the renewal date – include that option into your contract – but don’t promise too much, too early.
Bring the best out of your new engineering team by challenging them with development work that they can define, plan, design, build, test, deploy, launch, and support themselves. Give them the chance to demonstrate their value by writing new software, not maintaining other people’s code. Business As Usual (BAU) engagements can follow later on in the relationship and will be more successful after already establishing partner trust through R&D assignments.
Don’t overlook the importance of using modern technology wherever possible. New projects bring new technological opportunities, so don’t miss them.
Like everything else, technology deprecates, leaving room for more innovative, faster, more secure, better looking, development frameworks and platforms. Your engineers will also want to keep their skills and technical expertise up-to-date. Having the opportunity to use new technology is always an incentive for programmers. If you want the best engineers to join and stay, try to keep the stack as modern as possible. It will help you build a better, more motivated team.
Once you’ve identified the right project to partner on, it’s time to plan how to run it effectively. Start one project. Calibrate. Deliver. Learn from mistakes. Acknowledge them. Recalibrate. Provide feedback and ask for feedback. Celebrate success.
Here is our quick checklist to help you stay on track with your external engineering initiatives.
When embarking on your software engineering journey with a remote partner, you shouldn’t lose focus. Keep oversight and plan for regular catchups with the management. Feel free to set up goals and KPIs for the relationship but empower your team to make recommendations and speak up whenever they see room for improvement. Allow them to say no and give them the chance to explain.
If you found this article insightful, follow the Softelligence blog for more articles, how-to guides, and software delivery best practices.
*Note: We have designed this material to serve as a guideline for customers considering an external software engineering partnership for the first time. The guide represents our point of view and what we believe to be a practical way to engage with a new software engineering partner, based on our own experience in running international R&D projects for over 15 years.
We’d love to hear about your plans for transformation.
Use the form below to send us a message, and we will get back to you within 24 hours.
New Broad Street House, 35 New Broad Street, London, EC2M 1NH
4D Gara Herastrau Street, 2nd Floor
Building C, 020334
+40 31 425 19 08
30 Stirbei Voda Blvd,
Malmo Business Center, 200423
+40 35 142 36 80