A note on this archive: an earlier version of this site was lost in a migration, with no surviving backup. This piece is a good-faith recreation of our writing from this period, not a recovered original; its date reflects the period it represents. See about this archive.
It's been about three years since we wrote Part II of this little series, and the question behind it keeps coming up, so it's time for a Part III. It's always some version of the same thing: what can I safely hand to an outside developer, and what do I need to keep in-house?
Here's what's interesting. The honest answer in 2018 is different from the one we'd have given in 2015 — because the line has moved.
The line moved, and that's a good thing
A few years ago we were more cautious about what you could send outside, and for good reason: the tooling was clunkier, and a lot of teams hadn't learned how to work with someone they couldn't see. That's changed. Screen sharing, shared docs, and chat are everywhere now, and remote-first has become a discipline a team can actually learn. The result is that a lot more execution can be engaged outside, confidently, than we'd have signed off on three years ago.
So if you've been keeping work in-house out of an old assumption that "you can't really outsource development," it's worth re-checking that assumption. Plenty of teams are getting excellent work from developers who never set foot in their office.
But "more" is not "everything." Some things still shouldn't leave the building — not because of tooling, but because of what they are.
What still shouldn't be outsourced
The "why." Your product vision — what you're building and who it's for — is the one thing nobody outside your company can hold for you. You can get all the help in the world building it. Deciding what "it" should be is yours.
The decision of what to build, as opposed to the building of it. This is the distinction that matters most. Handing someone a clear spec and saying "build this well" is a great use of outside help. Handing someone a blank page and saying "figure out what we should do" isn't outsourcing — it's abdicating.
The senior judgment that defines the system. The architectural calls everything else hangs on — the ones we once called the black box of software architecture — need your most senior people in the room. You can absolutely bring in senior outside developers to inform and execute those calls. But the company should own the decision, because you're the one who lives with it for years.
The domain knowledge that is your edge. If understanding your customer better than anyone is what makes you you, don't ship that understanding out the door. Teach enough of it to work well with outside developers; keep the core.
What you absolutely can engage outside
The flip side is worth saying plainly, because some teams over-correct and try to do everything themselves while drowning:
- Execution capacity on a clear design. When you know what you want built, more good hands ship it faster.
- Specialized skills you don't need full-time. The deep expertise you need for three months, not three years.
- Scaling something that already works. Once the hard thinking is done, building more of it is exactly the kind of work that travels well.
And given how hard senior people are to hire right now, engaging outside help for the doing — so your in-house seniors can spend their time on the thinking — is often the smartest move on the board.
The rule that's held up
Three years and three parts later, it reduces to one line: don't outsource your thinking; get help with your doing. The teams that get burned almost always crossed exactly that line — they handed out a decision when they meant to hand out a task. Keep the judgment, share the execution, and outside help stops being a risk and starts being leverage.