“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.
Part 1: How to identify the RIGHT project to start with
- Start from the top. Ensure you have senior management support.
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.
- Get broad buy-in from stakeholders. Involve your technical team in the process.
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 what the working relationship might entail. This will help you obtain their buy-in for the initiative much faster.
- Select the right people for your internal team. Adopt a remote working culture and collaborative mindset.
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 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).
- Choose the right size and duration for your engagement.
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 a different geography and culture, it takes time to build common processes, personal chemistry, and 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.
- Go for R&D or Digital Product Development assignments, whenever possible.
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.
Part 2: How to run an engineering project effectively
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.
- Get a clear definition of roles and responsibilities. Before starting the project and allocating resources, it should be clear to all parties involved who will do what. (the “how” will be figured out later)
- Define success and share it with the team. Make sure everyone in the team knows “what success looks like” and how their work will be evaluated. What is really important to you? Since this is an early-stage partnership, your KPIs should also include qualitative factors towards building a strong working relationship with your remote team.
- Invest time to build chemistry with your new partner. Use video communication frequently to build positive social rapport with both technical delivery teams and top management. The effect will bring ten-fold long-term benefits (assuming you ARE interested in a long-term relationship).
- Plan for monthly management steerco’s; don’t be afraid to share the good, the bad, the ugly, but keep these meetings strategic. Let operational details be handled in other meetings, on a team level. Steercos should be strategic and should bring executive teams together for high-level evaluation and planning.
- Plan for future work. Think early about any future roadmap, possible subsequent releases, and how your new remote engineering team could come into play – assuming they do a good job during the Pilot assignment. Discuss such possible plans with your partner, to understand if there is more to the partnership than just a one-off.
- Don’t start many different projects with a new vendor at the same time. Allow your partner to focus and find the best way to collaborate and deliver for you. Onboarding too many people, too soon, may quickly prove to be counterproductive for a new partnership. Allow yourself and your internal teams to focus and strategize by not starting many different new engagements simultaneously.
- Bring your Product Owner on board. The one role that a new vendor cannot fill for you is the product management function. This will be your responsibility, as a Client. If you don’t already have a product owner, bring one in. You know your business; you know your market. This is not a technical role. Use a dedicated product owner and empower them to make decisions, set priorities, and clarify business requirements.
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 Encora Insights 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.
