How to Include Third-Party Developers as Creative Problem-Solvers
Collaborators, not coders
Building products is hard; not having your own engineering team makes it harder.
In the ideal world, software engineers are a cornerstone in building software. They collaborate closely with other team functions(PM, Design, etc) and contribute their brainpower.
Yet, for different reasons (budget, culture), not all product teams have their own developers. Outsourcing, then, seems to be the next best option. In the short run, outsourcing could make sense, but the downsides are severe: increased cost in communication, the client-vendor dynamic, the information lost during knowledge-transfer if you are to change vendors… to name a few.
To be blunt, I don’t think these challenges can be completely eliminated, no matter how hard you try. So before you resort to the economically better solutions, are you 100% certain you can’t have in-house engineers? Have you tried communicating the importance of that to leadership? Did you emphasize the long-term impact on the success of your business? Have you considered the impact on the rest of the team?
Still can’t have your own engineers? Well, sorry to hear.
Now, buckle up. Here are 4 tips to include your third-party engineers as creative problem solvers to the best degree.
1. Share the vision
Before you even start talking technology stack and diving into the nuts and bolts of feature requirements, share your product’s vision, your team’s values, etc. Explain things like
- How did this project start?
- Who are the external stakeholders outside your immediate team that affects the decision-making processes?
- So far, what are some critical pivoting points of the product up to now?
- What are your own team’s weaknesses and strengths? What have you tried that failed/succeeded?
- Product-wise and process-wise, what’s negotiable and what’s non-negotiable?
Clarifying these questions gives context and helps motivate your third-party team. Have a frank conversation around expectations from both sides.
I find doing so valuable for two reasons: first, developers likely have ideas that make the product vision better, because technical expertise is a source for innovative business. Developers’ inputs expand your own team’s existing understanding of what’s possible of the product. Even if those ideas aren’t immediately applicable, they might inspire you on other projects.
Secondly, sharing such information shows your respect and value for their perspectives. In addition to just understanding the product itself, getting aligned with the seemingly touchy-feely aspect helps morale and make them trust you more. It builds a culture where knowledge is respected. And culture has a direct impact on the quality of creative works.
2. Let go of the “I’m paying you, so just do as I say” syndrome
Normally, you hire someone because you trust their expertise. Keep it that way. Outsourced engineers already have to struggle — um, strive, to balance making good products v.s. pleasing the clients. Don’t make it harder.
Inexperienced managers don’t appreciate that development is a creative activity. Of course, your outsourced team is contractually obligated to meet your needs. But when they merely passively receive requests, they only deliver “outputs”; “outcomes” becomes less of a concern for them. Such a waste of potentials! At the minimum, technically qualified developers are capable to deliver outputs that you specified; but to bring the product game to the next level, developers need to feel empowered to share their creative ideas.
So, from the get-go, establish your respect and willingness to have developers as part of the problem-solving process. Nothing kills creativity like dictating attitudes.
Of course, it also doesn’t hurt to build rapport unofficially. With full-time team members, rapport-building comes naturally, so we tend to take it for granted. But when working with external teams, you have less “casual” time together (it’s also costly if you don’t do so early on), so the team needs to over-communicate to understand each other. Go out of your way to understand your developer’s work styles. Spend dedicated time to address directly on communication if necessary.
3. Mind the “small stuff”
Logistics matter. It should be a part of the leader’s job to make sure her team isn’t hampered by so-called “small things”.
Some obvious things to consider:
- Do they have access to the tools you use internally? Can you supplement better tools to increase their productivity?
- What do they mean by a jargon (e.g. what exactly is “1 point” when they estimate engineering work; What’s their definition of “test-driven development”)?
- What’s the “micro-culture” within their team? (Do they come to a consensus among themselves first then communicate with you? Or does each of their member speak up independently?)
- Do they have different local holiday schedules?
- Also, just because you’ve worked with Engineering team X in a certain way does not mean the same approach will be effective for Engineering team Y.
These subjects feel trivial, but teams’ productivity will hurt if the smaller things aren’t taken care of.
4. At all possibility, hire your own engineering lead
I am surprised I even have to say this, but some teams just don’t get it. Inexperienced leaders tend to think development is something you just tell devs to do and all will be fine. Don’t be like that. For a product team, saving money on this front is putting the cart in front of the horse.
This again comes back to viewing engineering as a creative problem-solving process. Having someone in your home team that speaks engineering language allows you to own the engineering decisions. That person should be able to oversee the quality of the engineering work done by the external team and communicate at the level of detail and honesty necessary to build strong products. If you don’t have a home engineering person, you lose control of your own products. Not to mention the extra money and time that will be spent on QA, operations, and customer support, and other downstream impacts.
At the end of the day, product building is collaborative creative work. So,
- Share your vision
- Respect engineers’ expertise
- Take care of the “small things”
- Hire your own engineer lead to own the engineering intelligence
Hopefully, this gets you to a point where you can have in-house engineers.
