For: tech entrepreneurs that are considering the options on where to source their development power from
It’s not an uncommon question. Should I outsource, should I create a distributed environment or should I keep everything (literally) in-house. There comes a time in nearly every company when these options will be (re) considered.
This blog post should shed some light at some possibilities and some of their pros and cons.
This is when you hire from your own county.
- One language that everybody understands
- You can easily walk up to someone
- Trust can be established by seeing someone at their spot
- It’s easy to bond
- Pair programming and doing coding dojo’s are easy to do
- You can facilitate a nice entourage and a real sense of being part of something big
- You’ll have to reimburse travel cost
- Hard to find competent or top-class people
- Because you can easily walk up to someone, you basically disturb them and a lot of effective time can go to waste
- Being at a spot, doesn’t say you are working or doing that efficiently
- When you find someone very competent from another country, you’ll have to relocate them
It’s easiest to start a company with local people. You can establish a brand, have short (but probably more inefficient) communication and reporting lines and you won’t have to take cultural differences in to account. Because you will have to set-up a facilitating environment anyway, it’s also a good base on which you can start working with interns and juniors so you can really supervise and even micro-manage every now and then (you shouldn’t but we all know it happens when you are still small).
This is where you completely carry over all development to an off-site company.
- It’s well known that some outsourced development is cheap as pennies in some countries.
- You can prototype and work in parallel
- You can hire for what you need. It’s scalable in that sense.
- You might get the features you’ve asked for, but who guarantees the quality and the longevity of the code
- You will have to meticulously write down every possible expectation of the product you wish for. Don’t assume it will be done for you.
- There is no intrinsic motivation or personal attachment to the quality of the product
- You will have to overcome cultural differences and stand firm when someone that works by different rules, laws and ethics disputes your requests or assumed rights.
I’ve tried this for a part of an application, but this backfired horribly. It’s hard to gain trust and monitor the quality. You could do this if the product is in example a tool that you just wanted as a prototype to get a better grip on your value proposition. One-time, never look back applications (e.g. apps) get developed like this all the time with good results. Working on a SaaS? Don’t do it, I would say.
The address is a formality, this is when there is no such thing as an office. Lots of pros and cons on working distributed have been mentioned above, so I’ll try to limit the pros and cons to only that what’s important and different if you work truly distributed
- There’s no overhead of physical buildings involved. This money can go directly in your company and its employees
- you will start judging people on their performance. “Did they do the thing I asked of them” will be more relevant than, “did he work 6 hours or 8, and did he work in the morning or evening”. This actually ties more in to the nature of people. Attendance is something less relevant than focus.
- You can work from EVERYWHERE. This is true for the developer, but also for the entrepreneur. Want to travel the world, but still get payed? This is the company to join!
- depending on how big the range of time difference is, it can be truly a madhouse to orchestrate everybody in to one virtual room.
- it’s harder to bond with the team.
- it’s harder to create a hierarchy or other form of ladder on which the developer can grow. Personal growth must be attended to, it is one of the prime concerns of any developer
I have seen and heard companies succeed in this setup. It brings its set of challenges but also benefits. I think that going truly distributed is not something for the fainthearted. Especially the entrepreneur will have to be the link between all developers. Every part of the process has to be looked at, cleaned, oiled and put back in. Is the documentation there. Is it in proper language. Are all code standards applied. Did he communicate nicely to his peers. etc etc. These are normally things you pass on to your leads and managers, but (especially when you start) should be done by the owner to ensure his company still sails the charted course. I would say that it’s not a natural first choice. You have to have the experience, and maybe it’s easiest to come there by progressively hire more external and bleed out local.
This is when you have the majority of your employees locally, but you also hire dedicated people abroad.
- dedicated workers for your company mean they (could or should) feel in line with the company’s goals
- working with different cultures really broadens your horizon. You’ll become more creative in work and this will reflect to your personal lives. It’s an absolute joy.
- no cost of commute
- having this division, enables you to not have all your eggs in one basket. (e.g. internet goes down at HQ, or everybody resents recent management changes and strike or find different jobs)
- When you hire through an agency, you are able to scale your external development faster.
- The infrastructure that you should get in place (think of cameras, digital boards, good documentation, communication pipelines etc) is also beneficial for your on-site employees. All of the sudden they can also efficiently work from home
- All communication should be in a language that everyone understands (most common is English). This future-proofs all documentation, code, etc and prepares your company for being true to serving the World Wide Web (distribute for everyone to read, all over the world).
- You still have a place to go to, a brand that can be visited
- once per X time you will have to gather, take the plane and meet each other for some time and do bonding. This is an expensive undertaking. I have heard from someone who actually has a fully distributed team that the cost is generically about the same as the cost of commute for local people (for a mid-sized company hiring in the same country).
- Initial setup can be demanding on people and budget.
- You will have to oblige to the law from wherever you hire. Some laws are really strict and can discourage experimenting with this way of working.
When you have the time and means to orchestrate this, I’d most definitely do this. It’s a perfect hybrid form that – even if it fails to work remotely – also greatly benefits your local team.
This will only succeed if you will have someone on the other side willing to understand and work with your company. Be critical about who to hire, especially the first one. But this will also only work if people on the local side bring this person in to all relevant discussions and support whenever this is needed.
Having the mindset and the infrastructure in place, you also create a nice environment for your local employees. They can work from home whenever needed, you remove ‘knowledge lock-ins’ in your team and individual and team performance will go up.
(in different time zones)
- able to run support and development 24/7
- the world truly is a bigger place than a specific timezone
- It becomes increasingly harder to communicate when someone lives further
- daily routines
- planning deadlines
- establishing unity within the company
(in the same timezone)
- Time of communicating is no issue
- The locations are generally ‘near’, so cost and time of traveling every once in a while shouldn’t become the main reason to do or not to do it
So you’ve probably read it well. The definition of how it’s properly done (DoD), resides in the distribution of development. It might not be low hanging fruit, but the stuff that hangs higher get’s more sun you know ;-). Striving for it might already make the difference. It’s up to you to decide how to implement it for your scenario.