Ask HN: How to keep overseas contractors aligned with non technical founders?

Engagement is more difficult because a foreign team may not understand some aspects of what they're building because of cultural differences. Time zones make communication more difficult and so clarifying stories or making product decisions is more difficult. More importantly is that for some of these foreign teams, they're part of a company that just wants to keep being paid. There's no incentive to finish projects early or at all.

That said there are some ways to make foreign development more engaged. Make sure the team is demoing the improvements made in this sprint. Give bonuses for accepted demos. Make sure that there is some communication window when the team can ask questions or just talk to the founders.

Most important find out why development is taking a long time. Is it because they've switched out developers or added junior developers? Is it because of new product decisions/scope creep? Are they focusing on the critical path? Is the dev team blocked overnight

Cool, thanks for the feedback. I think your suggestions are applicable for development teams regardless of location.

I would not take a startup that is outsourcing their development seriously. All of the institutional knowledge of how a product works goes right out the door. If you cannot fix your own product if it breaks, do you really own it?

Sure. However, the value of their company is really going to be the network and community they build. I believe they are planning to bring development in house as soon as they can afford it, but are trying to get the project going with the overseas team.

I think it would be a much more positive indicator if they had chosen to learn the skills necessary to create their product.

I agree. I mentioned a couple of times that they should learn the platform, or at least the underlying language. If not enough to code, at least enough to do quality control (code reviews).

However, they are both working apart from the startup (I believe) so it's tough for them to pick up one more thing.

That's a great point. It's one thing to be able to program it yourself, and another to understand enough to ask the right questions about the code to learn how it works.

If they had the ability to QA the outsourced team's work at a semi-granular level, I'd imagine there would be a lot less disconnect between the work done and expectations.

And one suggestion I offered was to find someone (some uninterested third party) to spend a few hours a week doing code reviews, so at least they have some insight. Of course, it'd be better if it were one of them, but some technical insight is better than next to none.

I disagree. Many companies I know started out by outsourcing development to some sort of agency and then brought some development in-house after the product is finished. Many agencies will give you a much stronger initial product, since they're used to making good v1 products.

Usually to be successful, the non-technical team must have complementary strengths, such as great domain knowledge and industry contacts, good sales ability etc. Purely technical startups are rarely successes outside of Silicon Valley, usually the tech needs to be married to a strong non-technical team that sets up sales, distribution networks, operations, etc

A couple of things spring to mind:

Naur's "programming as theory building" essay [1]. E.g.

  > programming properly should be regarded as an activity by
  > which the programmers form or achieve a certain kind of
  > insight, a theory, of the matters at hand. This
  > suggestion is in contrast to what appears to be a more
  > common notion, that programming should be regarded as a
  > production of a program and certain other texts

This suggests that it might not be a great idea to outsource understanding. The entire essay is worth a read.

Yosefk also gave a fairly amusing characterisation of what it is to work for a software company [2]:

  > Basically the "knowledge worker's" contract is
  > something like this:
  > 
  >   > We'll give you a precisely defined salary
  >   > and a benefits package. In return, we
  >   > request that you handle some problems that
  >   > we're told we're having. We hope that you'll
  >   > solve them well enough to prevent us from
  >   > having to know what they were in the first
  >   > place. Please help us maintain the feeling
  >   > that we own an asset similar to land or gold
  >   > or something. Please keep the realization
  >   > that we're more like the operator of a
  >   > flying circus than a landowner from
  >   > disturbing us. And certainly, never, ever
  >   > ask us what to do with any of the moving
  >   > pieces of this flying circus, because we
  >   > seriously have no idea.

[1] there's a copy here http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn...

[2] http://yosefk.com/blog/information-asymmetry-cuts-both-ways....

Wow, those are fantastic excerpts.

Thanks for sharing.

From my experience the only way to keep an external team engaged is to visit and to work with them. The longer, the better. During that time find out who are the best people to work with and make sure these folks stay on the project when you are away. Make a visit every 4-6 weeks and stay for at least 1 week.

Wow. Kinda cuts down on the cost savings, eh? Thanks for the advice.

Formally, the only way to align interests between a contractor and client is by expressing those interests in the contract and then both parties deciding that their primary interest is in execution of that contract. The essence of contracts is to resolve unaligned interests.

Informally, relationships usually do much more. However, finding the right contractor for that kind of relationship is going to be harder than hiring someone. Probably more expensive to boot because the needs of a contractor are salary + overhead + profit.

To put it another way, the popular YC advice about hiring should probably double down for engaging contractors for anything critical: careful interview for competence and culture.

I should mention that they were way over budget and over schedule, and that they were using a relatively obscure third party platform to build their application.

Most software developers love to deliver. If the overseas contractors have slowed down to a crawl, it's probably not that they aren't "aligned" or willing, but that they can't.

If they had the ability to fix the project themselves or their process, they would have.

The usual non-technical customer approach would be to demand or plead for the developers to work harder. I've never seen this turn a problem overseas project into a successful one.

To unstick, you've got to first is to figure what is wrong, and secondly fix that.

But at this point, you don't know what is wrong, and developers don't know what is wrong or find it culturally impossible to communicate the problem.

I'd recommend getting some skilled local technical talent to take a look at the code and the recent commits to get a feel for what the underlying problem is.

-

Off the top of my head, the four mostly likely problems would be:

1. Frameworkitis - Many frameworks, when doing something the framework is not designed to do, require far more code than would normally be require. This even ends up hitting harder since often these overrides must be done in ways that either can't be reused, or must be done in one place, tangling everything together.

2. Overwhelming technical debt - Spaghetti code, untested business logic, the usual.

3. Too much business complexity in the code - Given that the cofounders are not technical, they may have been asking for things that make for a lot of complexity, and the development team may not have pushed back. This can kill later development, since adding new features to complex systems is usually much more difficulty. Alternately, since this is a new business, it's possible that the requirements have been changing, leaving the system more complicated than it needs to be.

4. The developers could simply not have the skills required - A company had me see if I could speed up their application. It was days away from launch. The home page took EIGHT MINUTES to load. (with no customers using the site, only 50,000 records in the database, and static data that only changed every couple months.) Eight minutes to generate a single page!

The customer had been telling the overseas developers that this was a problem for weeks. The overseas developers were unable to figure out why, for weeks. After tracking down the problem, I added a cache in front of one piece of code, and took the site from an eight minute page generate time down to under a second.

The speed problem was not just due to a terrible architecture, nor a complete ignorance of what the frameworks involved were doing under hood, but mostly that not one person on the overseas team - even the "senior" developer - know that it was possible to find out which parts of code are slow.

-

To summarize again, probably the contractors cannot fix whatever is currently wrong, and outside eyes are needed.

Thanks for the feedback. More details.

1. Could definitely be the case. I'm not familiar enough with the framework to say how flexible it si.

2. Can't imagine there is a ton of technical debt, since this project is less than a year old and is greenfield.

3. Could definitely be that. I scanned the current backlog and it seems like a big project, but have no insight into "the weeds".

4. I guess this is a possibility, though the fact that they delivered some good work early in the engagement points away from this. Great story though! (8 minutes, OMG!)