In previous roles as head of Product, I’ve loved the satisfaction of teaming up with developers to create something genuinely useful for our users. I’ve worked with every variety of tech team — from working with company devs in the same (tiny!) room for days on end, to supplementing a local team with embedded free-lancers, up to working with fully remote, out-source developers. Each set up has its pros and cons.
In-house Development Teams:
Being co-located makes communication easier, especially in an agile environment where specifications are less detailed/prescriptive than in a traditional waterfall environment. PMs expect to have conversations with the developers about the best way to fulfil a user-goal, and being co-located can speed things up. When working with remote teams, we dealt with the distance using daily VoIP huddles and constantly open team chat windows, mostly over Skype. We also had a weekly grooming sessions and a simple retro session after every sprint using the happy/sad/bad/mad shorthand on a “virtual corkboard” (we’d use Trello today) so that teams could participate remotely. Essentially, members of the team would have a few minutes to create one or two line cards in any of those sections and other could upvote them, then we’d discuss over Skype — a quick and easy way to surface issues and best practice in a structured conversation.
A sense of ownership
When product and in-house dev teams are working together, it’s easier to foster a sense of common purpose, which leads to better outcomes. Plus, in-house teams will have a better understanding of the customers’ needs and the company’s vision, from proximity to the customer services team, marketing, exec team, etc. The sense of ownership translates to teams that are generally more likely to go the extra mile in terms of early mornings and late nights, an occasional occupational hazard of releasing into a production environment.
Nothing builds trust like working together day-in/day-out with your colleagues. It’s just that much harder to build those key relationships remotely.
Out-source development team
Many of our portfolio CEOs and CTOs spend a big part of their week recruiting. There are various tools to make it easier, from ATS tools like Hired.com, sourcing from developer community sites like Stackoverflow, or using specialist recruiters but that’s a whole other post. Regardless, hiring developers is difficult. You may want nothing better than to hire in-house, but if you don’t have the time, relationships or funding to hire in, out-source development can be the best/only option to get a product shipped. We usually see this issue with very early stage teams who don’t have a technical co-founder and have a relatively simple product, but are keen to a get a demo out to validate their idea and hopefully attract investment and team members, or else later stage companies that need to scale up talent more quickly than their recruitment pace.
Full-time employees are expensive, especially in central London. Out-sourcing development to offshore agencies is usually significantly cheaper and can work really well if there is a well-defined piece of work, ongoing or not, that can have a specific team / product manager combination that works on a project together. Hiring an agency in London will be more expensive, but can provide access to very specialised talent, and an agency should work with you to define the cost of a project by a specific deliverable at the end of it.
In-house teams can’t be scaled up or down at short notice. It takes time and effort to recruit good people and similarly, time to downsize a team. If you have a well-defined project, or you need to scale up and down at short notice, it can make sense to out-source development.
On balance, working with in-house teams has yielded the best professional and personal results for me as a product owner. Releases have generally been smoother, and product iterations faster. The combination of easy communication, deep product understanding by the in-house team, and the trusted relationships to rely on when things inevitably go wrong at times, outweighed the cons of higher costs, lower flexibility and hassle of recruiting. That said, there are lots of ways to minimise the cons of an out-source team. Please follow me on Twitter @tarareeves if you’ve enjoyed this and stay tuned for Part II — How to get the most of your out-source development team.