
Ask HN: How to keep overseas contractors aligned with non technical founders? - mooreds
I recently chatted with a startup.  The two cofounders are in a space I&#x27;m interested in (food).  We had engaged briefly a while ago, but this time I was just providing a sanity check for their development process.  Neither founder is technical, though one is a project manager.<p>They are dismayed with their current development team.  This is an overseas team, hired through a site like oDesk (not sure which one).  This is the second team they&#x27;ve worked with, having parted ways with the first one.  The founders were wondering about ways to keep the current team engaged and productive.  When this team was first hired, they were very productive (in terms of stories completed, etc), but now the pace seems to have slowed down.<p>I&#x27;ve worked with overseas teams occasionally, but usually with technical talent on both sides.  I suggested a few things to help keep everyone aligned, but was curious what HNers thought.<p>I&#x27;d also be curious if anyone has found engagement to be more difficult because of time zone and&#x2F;or culture differences.
======
twunde
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

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

------
neilwillgettoit
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?

~~~
shoo
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...](http://alistair.cockburn.us/ASD+book+extract%3A+%22Naur,+Ehn,+Musashi%22)

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

~~~
mooreds
Wow, those are fantastic excerpts.

Thanks for sharing.

------
tlubinski
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.

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

------
brudgers
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.

------
mooreds
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.

------
danielvf
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.

~~~
mooreds
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!)

